Date: Fri, 2 Mar 2012 13:23:48 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Tijl Coosemans <tijl@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Dimitry Andric <dim@freebsd.org>, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r232266 - in head/sys: amd64/include i386/include pc98/include x86/include Message-ID: <20120302130435.J929@besplex.bde.org> In-Reply-To: <201203012346.20648.tijl@freebsd.org> References: <201202281939.q1SJdtYr084858@svn.freebsd.org> <20120229160522.W2514@besplex.bde.org> <20120229181608.S2887@besplex.bde.org> <201203012346.20648.tijl@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120302130435.J929>