svn commit: r232266 - in head/sys: amd64/include i386/include pc98/include x86/include

[Bruce Evans]

On Thu, 1 Mar 2012, Tijl Coosemans wrote:

> On Wednesday 29 February 2012 08:44:54 Bruce Evans wrote:
>> ...
>> So any macro version must use gcc features to be safe.  The following
>> seems to work:
>>
>> #define	__bswap16(x)	__extension__ ({ __uint16_t __x = x;
>>  	(__uint16_t)(__x << 8 | __x >> 8); })
>>
>> clang now produces "rolw $8,x" when x is volatile.  This seems to
>> violate volatile semantics.  gcc produces load-rolw-store then.  Both
>> produce "rolw $8,x" when x is not volatile.
>
> I'll have a closer look at the patch tomorrow, but the Intel
> documentation for the bswap instruction recommends to use xchg for
> bswap16.

That's what i386 used to do, using an asm (see for example the RELENG_4
version), but the asm was replaced by C code and the compiler apparently
knows better.  This might depend on -mtune.  I tested with the default,
which is poorly documented and hard to remember, but what I remember is
that it is for a really old Intel CPU.  Checking the documentation shows
that the default might be the same as -mtune=generic which is the same
as -mtune=i686, where i686 seems to be undocumented but seems to be
similar to pentiumpro.  I would have to run old tests to verify this.
There must also be magic to break i386 support, so that bswap gets used.
The current default is certainly not -march=i386 like it used to be,
but the details of what it now is seem to be undocumented.  It doesn't
include SSE support, since it is only for a really old Intel CPU; just
one that is not quite as old as plain i386.

Bruce