lkml.org 
[lkml]   [2004]   [Feb]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: Intel vs AMD x86-64
Date
From
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@suse.de [mailto:ak@suse.de]
>Sent: Tuesday, February 24, 2004 3:49 PM
>To: Nakajima, Jun
>Cc: linux-kernel@vger.kernel.org
>Subject: Re: Intel vs AMD x86-64
>
>"Nakajima, Jun" <jun.nakajima@intel.com> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.039 / U:1.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site