ml64 = useless piece of ...

I had to find out the hard way. =:O

------------------------ 8 < -----------------------
Microsoft (R) Macro Assembler (x64) Version 9.00.21022.08 09/05/08
22:30:53
bug.asm Page 1 - 1


00000000 .CODE

00000000 main PROC
00000000 41/ B8 mov r8d, NOT 80000000h
7FFFFFFF FF FF
FF FF
0000000A C3 ret
0000000B main ENDP

END
------------------------ 8 < -----------------------

> 00000000 41/ B8 mov r8d, NOT 80000000h
> 7FFFFFFF FF FF
> FF FF

Looks like this happens with _all_ 32 bit registers, i.e.

"mov eax, NOT 80000000h"

will produce

"B8 FF FF FF 7F FF FF FF FF"


Microsoft have invented "mov r32, imm64", which might make sense to
Microsoft, but unfortunately, it does _not_ make sense to any existing
processor.

Since it's Microsoft, it _must_ be the processor's fault, however!

"Michael Tippach" posted:

>> 00000000 41/ B8 mov r8d, NOT 80000000h
>> 7FFFFFFF FF FF
>> FF FF

> Looks like this happens with _all_ 32 bit registers, i.e.
>
> "mov eax, NOT 80000000h"
>
> will produce
>
> "B8 FF FF FF 7F FF FF FF FF"
>
>
> Microsoft have invented "mov r32, imm64", which might make sense to
> Microsoft, but unfortunately, it does _not_ make sense to any existing
> processor.
>
> Since it's Microsoft, it _must_ be the processor's fault, however!


I'm afraid your compiler may be confused by the NOT, the CPU will
(correct) interprete only imm32 without REX.

__
wolfgang

Michael Tippach posted:

>> 00000000 41/ B8 mov r8d, NOT 80000000h
>> 7FFFFFFF FF FF
>> FF FF

> Looks like this happens with _all_ 32 bit registers, i.e.
>
> "mov eax, NOT 80000000h"
>
> will produce
>
> "B8 FF FF FF 7F FF FF FF FF"

seem to wrong compile ...
even the result of 'NOT 8000_0000' may end up as a 64 bit value.


> Microsoft have invented "mov r32, imm64", which might make sense to
> Microsoft, but unfortunately, it does _not_ make sense to any existing
> processor.

Yeah, and AMD responeded with a quiet auto-zero-extend to this

> Since it's Microsoft, it _must_ be the processor's fault, however!


I'm afraid your compiler may be confused by the NOT, the CPU will
correct interprete B8 imm32 without REX.

__
wolfgang

On Sep 6, 12:33*am, "Wolfgang Kern" <spamt...@crayne.org> wrote:
> Michael Tippach posted:
>
> >> *00000000 *41/ B8 * * * * * *mov * *r8d, NOT 80000000h
> >> * * * *7FFFFFFF FF FF
> >> * * * *FF FF
> > Looks like this happens with _all_ 32 bit registers, i.e.
>
> > "mov eax, NOT 80000000h"
>
> > will produce
>
> > "B8 FF FF FF 7F FF FF FF FF"
>
> seem to wrong compile ...
> even the result of 'NOT 8000_0000' may end up as a 64 bit value.
>
> > Microsoft have invented "mov r32, imm64", which might make sense to
> > Microsoft, but unfortunately, it does _not_ make sense to any existing
> > processor.
>
> Yeah, and AMD responeded with a quiet auto-zero-extend to this
>
> > Since it's Microsoft, it _must_ be the processor's fault, however!
>
>
> I'm afraid your compiler may be confused by the NOT, the CPU will
> correct interprete B8 imm32 without REX.
>
> __
> wolfgang

Heh, the C standard says how conversions and promotions are to be
done, but there is no standard for the assembly language. As long
as the assembler correctly generates code for the instructions from
the CPU manual, it's correct. Things like NOT and negation aren't part
of the CPU spec. And not just that. I used an assembler that didn't
honor the relative precedence of */ and +-. I had to use many
parentheses.

Alex

Sorry for I have no idea why my post show up three times here.
Perhaps because I modified it before I hit the send-button ?

It's just windoze my son, just windoze ...
and of course I see no reason for a smily yet,
even humour may be the best way to overcome all these M$-given odds.
__
wolfgang

Alexei A. Frounze wrote:
> As long as the assembler correctly generates code for the instructions from
> the CPU manual, it's correct.

Point is that it does _not_. It generates an extra four FF-s, which will
cause an #UD, obviously.

Wolfgang Kern wrote:

> I'm afraid your compiler may be confused by the NOT, the CPU will
> correct interprete B8 imm32 without REX.

But that is the whole point: MASM will emit an immediate operand EIGHT
bytes in size. The CPU will dutifully execute the "mov r32, imm32" and
will _then_ be left with "FF FF FF FF" to decode next...

On Sep 6, 2:10*pm, Michael Tippach <spamt...@crayne.org> wrote:
> Alexei A. Frounze wrote:
> > As long as the assembler correctly generates code for the instructions from
> > the CPU manual, it's correct.
>
> Point is that it does _not_. It generates an extra four FF-s, which will
> cause an #UD, obviously.

What if you remove NOT?

Alex

Alexei A. Frounze wrote:
> What if you remove NOT?

Please don't misunderstand me, I'm not here asking for help. I have
worked around this since.

Still, it is a flaw that could hit anyone fairly in not just the most
unusual of circumstances.

Obviously, my original code was not just "mov eax, NOT 80000000", but
rather it went sort of like this:

FLAG_A EQU 00000001h
FLAG_B EQU 00000002h
FLAG_C EQU 00000004h
....
FLAG_X EQU 80000000h


....basic bit mask operation stuff. Now, if one wants to create a mask of
some sort, it could be like:

"mov eax, NOT FLAG_X"

....how uncommon is _that_? Yet it makes MASM generate code that will
fault the CPU, when executed.

I consider this a quite serious flaw.