RE: Intel vs AMD x86-64

[Nakajima, Jun]

I think we have a bug in the inline function. Actually this behavior is 
consistent with the IA-32, which says "if the contents source operand
are 0, 
the contents of the destination operand is undefined." So the code in
32-bit 
also has a bug there. Today it is set to zero fortunately, and the code 
happens to be working.

Jun

>-----Original Message-----
>From: ak@xxxxxxx [mailto:ak@xxxxxxx]
>Sent: Tuesday, February 24, 2004 3:49 PM
>To: Nakajima, Jun
>Cc: linux-kernel@xxxxxxxxxxxxxxx
>Subject: Re: Intel vs AMD x86-64
>
>"Nakajima, Jun" <jun.nakajima@xxxxxxxxx> writes:
>
>> Other than the standard IA-32 differences (eg. HT, SSE3, Intel
Enhanced
>> SpeedStep, etc.), there are few differences between the
implementations
>> of
>> IA-32e and AMD64. The software visible ones are:
>
>Thanks for the detailed list.
>
>> BSF/BSR when source is 0 & operand size is 32:
>>   In 64-bit mode, the processor sets ZF, and the upper 32 bits of
>>   the destination are undefined. Should always check the ZF or do not
>> use
>>   32-bit operand size.
>
>This one sounds a bit scary. I think it could hurt the
>asm-x86_64/bitops.h:find_first_zero_bit if there is a race that
>changes the value in memory between the last scasl and the bsfl
>and the inliner assumes the edx output argument is zero extended.
>Hopefully that case should be unlikely enough. I guess best would
>be to change the function to use 64bit accesses to avoid this
completely.
>
>-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/