ml64 = useless piece of ...

"Michael Tippach" <spamtrap@crayne.org> wrote in message
news:g9v66n$elk$01$1@news.t-online.com...
> Alexei A. Frounze wrote:
> > What if you remove NOT?
>
> Please don't misunderstand me, I'm not here asking for help.

I'm not sure what Alex was getting at, but this is what I was thinking:

Is the "NOT" the cause of problem or is it something else, like the
assembler treating all register sizes as 64-bits?

Just as Alex's remove the NOT post popped up, I was about to ask this:

What do these compile to? Are the constants 64-bits or 32-bits?

"mov r8d, 80000000h"
"mov eax, 80000000h"


Rod Pemberton

Michael Tippach replied:
> 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...

Yeah, this is a M$-owned compiler bug and may need the NOT apart:

MOV eax, x_flag ;sign-bit
NOT eax
__
wolfgang

Alexei A. Frounze wrote:
....
>>> 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.

> 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.

Even I'm for sure not a friend of HLL-ismen in assembler,
round parantheses may be a good choice to give the compiler a
hint which expressions are RunTime or CompileTime calculations.

But what Michael encountered/reported is a serious bug anyway.
__
wolfgang

On Sep 6, 6:07*pm, "Rod Pemberton" <spamt...@crayne.org> wrote:
> "Michael Tippach" <spamt...@crayne.org> wrote in message
>
> news:g9v66n$elk$01$1@news.t-online.com...
>
> > Alexei A. Frounze wrote:
> > > What if you remove NOT?
>
> > Please don't misunderstand me, I'm not here asking for help.
>
> I'm not sure what Alex was getting at, but this is what I was thinking:
>
> Is the "NOT" the cause of problem or is it something else, like the
> assembler treating all register sizes as 64-bits?
>
> Just as Alex's remove the NOT post popped up, I was about to ask this:
>
> What do these compile to? *Are the constants 64-bits or 32-bits?
>
> "mov r8d, 80000000h"
> "mov eax, 80000000h"
>
> Rod Pemberton

There're plenty of ways to simulate NOT, some may even work:
NOT X = X XOR 111...111B = 111...111B - X = -(X + 1)
If the number of generated bytes depends on the value, then maybe
adding an AND could fix the problem: mov eax, (NOT FLAG_X) AND
0FFFFFFFFH

Sounds like a regression, since with the older version (from Windows
Server 2003 R2 Platform SDK) I get this:
------------------------ 8 < -----------------------
Microsoft (R) Macro Assembler (AMD64) Version 8.00.40310.39 09/07/08
02:58:08
bug.asm Page 1 -
1


00000000 .CODE

00000000 main PROC
00000000 41/ B8 mov r8d, NOT 80000000h
7FFFFFFF
00000006 C3 ret
00000007 main ENDP

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

Alex

Rod Pemberton wrote:
> "Michael Tippach" <spamtrap@crayne.org> wrote in message
> news:g9v66n$elk$01$1@news.t-online.com...
>> Alexei A. Frounze wrote:
>>> What if you remove NOT?
>> Please don't misunderstand me, I'm not here asking for help.
>
> I'm not sure what Alex was getting at, but this is what I was thinking:
>
> Is the "NOT" the cause of problem or is it something else, like the
> assembler treating all register sizes as 64-bits?
>
> Just as Alex's remove the NOT post popped up, I was about to ask this:
>
> What do these compile to? Are the constants 64-bits or 32-bits?
>
> "mov r8d, 80000000h"
> "mov eax, 80000000h"
>
>
> Rod Pemberton
>

It is entirely independent of which register you use, eax is as good or
bad as r8d. The bug seems to be with the evaluation of the NOT and seems
to hit all immediate operands with the high bit set.

Thus, it seems someone's using signed arithmetic where not appropriate.
It's the implementation of the NOT, methinks. ANDing the result with a
32 bit mask brings it back to normal, as can be seen below.

The best way so far I figured to find out if your code is affected is to
generate listings on all .ASM files in you project and than grep these
for instances of the string "FF FF FF".


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


00000000 .CODE

00000000 main PROC
00000000 B8 80000000 mov eax, 80000000h
00000005 B8 7FFFFFFF mov eax, 7FFFFFFFh
0000000A B8 00000000 FF mov eax, NOT 0FFFFFFFFh
FF FF FF
00000013 B8 00000000 mov eax, ((NOT 0FFFFFFFFh) AND 0FFFFFFFFh)
00000018 C3 ret
00000019 main ENDP

END