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
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
