Messages in this thread | | | Subject | RE: Intel vs AMD x86-64 | Date | Tue, 24 Feb 2004 19:07:17 -0800 | From | "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@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/
| |