AND with 64-bit immediate

[aw27]

option casemap:none
IFDEF __JWASM__
option frame:auto
OPTION WIN64:2
ENDIF

.code


main proc
   mov rax, 0EEEEEEEEEEEEEh
   and rax, 5555555555555555h
   and rax, 71D67FFFEDA60000h
   and rax, 0FFF7EEE000000000h
   ret
main endp

end


COMMENT ?

UASM happily compiles nonsense. Same with OR, XOR,...

00000001`3fc51000 4883ec08        sub     rsp,8
00000001`3fc51004 48b8eeeeeeeeeeee0e00 mov rax,0EEEEEEEEEEEEEh
00000001`3fc5100e 482555555555    and     rax,55555555h
00000001`3fc51014 48250000a6ed    and     rax,0FFFFFFFFEDA60000h
00000001`3fc5101a 4883e000        and     rax,0
00000001`3fc5101e 4883c408        add     rsp,8
00000001`3fc51022 c3              ret


JWASM gives error

test64.asm(12) : Error A2235: Constant value too large: 5555555555555555h
test64.asm(13) : Error A2235: Constant value too large: 71D67FFFEDA60000h
test64.asm(14) : Error A2235: Constant value too large: FFF7EEE000000000h

MASM gives error

test64.asm(12) : error A2084:constant value too large
test64.asm(13) : error A2084:constant value too large
test64.asm(14) : error A2084:constant value too large

?

[jj2007]

I feel tempted to write that real men^TM don't need an assembler holding their little hot hands, they simply know that and imm is limited to a DWORD

[aw27]

I feel tempted to write that real men^TM don't need an assembler holding their little hot hands, they simply know that and imm is limited to a DWORD

Are you done with your investigation to print the 128-bit float hidden inside the xmm0 register?

[jj2007]

Are you done with your investigation to print the 128-bit float hidden inside the xmm0 register?

Yessir! I can print 128-bit floats now, but why "hidden inside the xmm0 register"?

[aw27]

PrintLine "xmm0=", Tb$, Quad$(xmm0)
PrintLine "MyReal16=", Tb$, Quad$(MyReal16)

I am happy you can print 128-bit floats in MASM BASIC not only from the xmm0 register but from other sources as wel, all that without even knowing the specification that will be adopted. 

[jj2007]

Sorry, I still don't understand what you mean. Are you alluding to the diff<>0 problem with the float conversion? Or something else? Which specification that "will be adopted"? I am curious ::)

[aw27]

Probably you are in a wrong thread, JJ. You never find bugs in UASM, you can't use a 64-bit debugger. Why are you trying to be smart with me? You know so little about programming.
Please open a thread in another subforum.

[jj2007]

you can't use a 64-bit debugger. Why are you trying to be smart with me? You know so little about programming.

José, I made a harmless little insider joke, addressed more to Hutch (who is a fan of ML64 :P) than to you:

I feel tempted to write that real men^TM don't need an assembler holding their little hot hands, they simply know that and imm is limited to a DWORD

Why do you think you can insult me?

"without even knowing the specification"
"you can't use a 64-bit debugger"
"You know so little about programming"

Do you seriously think that I found, for example, this fairly complex code, which builds and runs in 64-bit or 32-bit mode with ML64, AsmC, HJWasm and UAsm, somewhere on the Internet, and posted it here?

This is really absurd. You must have real problems if you behave like this.

[aw27]

Why do you feel obliged to insult me?

From what I am seeing lately, it is becoming fashion in here someone starting the provocations then playing the victim.

[habran]

ML64 is s*itty and JWasm is obsolete, however aw27, you are right in one hand but wrong in another ;)
it is legal for MOV to use 64 bit constant, but only for MOV, other instructions are not allowed
It has been fixed now that problem and if used greater constant than FFFFFFFFh error will be reported
so here is an example:

Code: [Select]

    42:    and rax, 12345678h
00007ff79c4d1014 48 25 78 56 34 12                and rax, 0x12345678 
    43:    mov rax, 123456789abcdefh
00007ff79c4d101a 48 B8 EF CD AB 89 67 45 23 01    mov rax, 0x123456789abcdef
 
if used a greater than DWORD for the rest instructions it does that:

Code: [Select]

1>aw.asm(42): error A2236: Constant value too large: 123456789ABCDEFh
1>aw.asm(44): error A2236: Constant value too large: 5555555555555555h
1>aw.asm(45): error A2236: Constant value too large: 71D67FFFEDA60000h

when ever Johnsa get some time he will upload a fixed version

[aw27]

ML64 is s*itty and JWasm is obsolete, however aw27, you are right in one hand but wrong in another ;)
it is legal for MOV to use 64 bit constant, but only for MOV, other instructions are not allowed
It has been fixed now that problem and if used greater constant than FFFFFFFFh error will be reported

Yes, I know that, fortunately it slipped from my hand  (giving you a chance to fix or ask Johnsa to fix) while I was converting to 64-bit ASM for the first time in History the most important Pseudo Random Number Generator ever invented. Nobody noticed that part.

[johnsa]

New packages are up dated today, 31st with the fix to limit immediate values to <= DWORD size except for MOV rax, ..

John

[hutch--]

Isn't MASM disgusting, trick is to load large constant into a 64 bit register first.

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    include \masm32\include64\masm64rt.inc

    .code

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

entry_point proc

    LOCAL var   :QWORD

    mov rax, 123456789012345678
    mov var, rax
    conout str$(var),lf

    waitkey
    .exit

entry_point endp

; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤

    end

Producing,

123456789012345678
Press any key to continue...

 

[jj2007]

Isn't MASM disgusting, trick is to load large constant into a 64 bit register first.

Right. But the and immediate64 problem is even trickier than that:

include \Masm32\MasmBasic\Res\JBasic.inc        ; builds with ML, UAsm, AsmC, JWasm
usedeb=1                                        ; OPT_64 1
Init
  PrintLine Chr$("This code was assembled with ", @AsmUsed$(1), " in ", jbit$, "-bit format")

  ; int 3
  mov rbx, 01234567890ABCDEFh   ; a debug-friendly 64-bit number
  and rbx, 0FFFFFFFFFFF0FFFFh   ; 64 bit constant, accepted by ML64*); gets encoded as and rbx, 0xFFFFFFFFFFF0FFFF
  ; and rbx, 0FFFFFFFFFF0FFFFh  ; 60 bit constant, not accepted by ML64
  deb 4, "and 64", x:rbx        ; the b should have disappeared
  mov rbx, 1234567890ABCDEFh
  and rbx, 0FFF0FFFFh           ; gets encoded as and rbx, 0xFFFFFFFFFFF0FFFF
  deb 4, "wrong", x:rbx

  mov rbx, 1234567890ABCDEFh
  mov rax, 0FFFFFFFFFFFFh       ; the right way to keep 12 bytes
  deb 4, "before", x:rbx
  and rbx, rax
  deb 4, "after", x:rbx
  Inkey
EndOfCode

Output:

Code: [Select]

This code was assembled with ml64 in 64-bit format
and 64  x:rbx   1234567890a0cdefh
wrong   x:rbx   1234567890a0cdefh
before  x:rbx   1234567890abcdefh
after   x:rbx   567890abcdefh
*) The tricky issue here is that assemblers read a 64-bit number as a 32-bit number, then sign-extend it. Since and operations are often done with negative numbers, the phenomenon has great practical relevance.

The logic of the UAsm bug is the following (using José's original example):

and rax, 071D67FFFEDA60000h     ; EDA60000 is negative as 32-bit number
The high order bits are ignored, and UAsm encodes it as:
and rax, 0FFFFFFFFEDA60000h     ; so sign extension happens

This behaviour will rarely cause problems, though - which makes it a dangerous bug.

In the attached exe, the int 3 is enabled. Note this is the ML64-assembled exe, but the others behave the same.

[habran]

JJ, that problem has been fixed, you can trow what ever you want on UASM it will spit out error for bull

Code: [Select]

1>aw.asm(42): error A2236: Constant value too large: FFF7EEE000000000h
1>aw.asm(43): error A2236: Constant value too large: 123456789ABCDEFh
1>aw.asm(45): error A2236: Constant value too large: 5555555555555555h
1>aw.asm(46): error A2236: Constant value too large: 71D67FFFEDA60000h
1>aw.asm(47): error A2236: Constant value too large: FFF7EEE000000000h

aw27, you can often be very unpleasant(forgive me for being gentle with that expression) person, however, thank you for finding bugs which nobody else would dare to produce :t