From owner-svn-src-head@FreeBSD.ORG Tue Feb 28 20:56:01 2012 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2ADD7106564A; Tue, 28 Feb 2012 20:56:01 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id DE5CF8FC08; Tue, 28 Feb 2012 20:56:00 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:40c7:bfc6:1449:f9dd] (unknown [IPv6:2001:7b8:3a7:0:40c7:bfc6:1449:f9dd]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 875A05C37; Tue, 28 Feb 2012 21:55:58 +0100 (CET) Message-ID: <4F4D3F5D.70905@FreeBSD.org> Date: Tue, 28 Feb 2012 21:55:57 +0100 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120216 Thunderbird/11.0 MIME-Version: 1.0 To: Tijl Coosemans References: <201202281939.q1SJdtYr084858@svn.freebsd.org> In-Reply-To: <201202281939.q1SJdtYr084858@svn.freebsd.org> X-Enigmail-Version: 1.4a1pre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r232266 - in head/sys: amd64/include i386/include pc98/include x86/include X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 20:56:01 -0000 On 2012-02-28 20:39, Tijl Coosemans wrote: > Author: tijl > Date: Tue Feb 28 19:39:54 2012 > New Revision: 232266 > URL: http://svn.freebsd.org/changeset/base/232266 > > Log: > Copy amd64 endian.h to x86 and merge with i386 endian.h. Replace > amd64/i386/pc98 endian.h with stubs. > > In __bswap64_const(x) the conflict between 0xffUL and 0xffULL has been > resolved by reimplementing the macro in terms of __bswap32(x). As a side > effect __bswap64_var(x) is now implemented using two bswap instructions on > i386 and should be much faster. __bswap32_const(x) has been reimplemented > in terms of __bswap16(x) for consistency. ... > +#define __bswap32_const(_x) \ > + (((__uint32_t)__bswap16(_x) << 16) | __bswap16((_x) >> 16)) > + > +#define __bswap32(_x) \ > + (__builtin_constant_p(_x) ? \ > + __bswap32_const((__uint32_t)(_x)) : __bswap32_var(_x)) > + > +#define __bswap64_const(_x) \ > + (((__uint64_t)__bswap32(_x) << 32) | __bswap32((_x) >> 32)) Hmm, shouldn't __bswap32_const() be implemented in terms of __bswap16_const(), and similarly for __bswap64_const(), which should be implemented in terms of __bswap32_const()? The whole reason for the difficult dance with __builtin_constant_p is to allow for compile-time resolving of bswap'd constants. Invoking the regular __bswap() macros doesn't gain you anything here.