From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1HNUF5-00063B-EN
	for qemu-devel@nongnu.org; Sat, 03 Mar 2007 08:25:43 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1HNUF3-00060F-Qd
	for qemu-devel@nongnu.org; Sat, 03 Mar 2007 08:25:42 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1HNUF3-0005zu-IJ
	for qemu-devel@nongnu.org; Sat, 03 Mar 2007 08:25:41 -0500
Received: from vc4-2-0-87.dsl.netrack.net ([199.45.160.85]
	helo=harmony.bsdimp.com) by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1HNUF2-0007HE-WA
	for qemu-devel@nongnu.org; Sat, 03 Mar 2007 08:25:41 -0500
Date: Sat, 03 Mar 2007 06:24:52 -0700 (MST)
Message-Id: <20070303.062452.129711022.imp@bsdimp.com>
Subject: Re: [Qemu-devel] [PATCH] pcnet32 driver change, please test
From: "M. Warner Losh" <imp@bsdimp.com>
In-Reply-To: <jemz2uvd2u.fsf@sykes.suse.de>
References: <20070302.175333.1622572844.imp@bsdimp.com>
	<200703030101.56126.paul@codesourcery.com>
	<jemz2uvd2u.fsf@sykes.suse.de>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org, schwab@suse.de

In message: <jemz2uvd2u.fsf@sykes.suse.de>
            Andreas Schwab <schwab@suse.de> writes:
: Paul Brook <paul@codesourcery.com> writes:
: 
: >> : I find this curious...  C99 (6.7.2.1) says "the allocation order of
: >> : bit-fields within a unit (high-order to low-order or low-order to
: >> : high-order) is implementation defined".  I can't see any requirement
: >> : for this, so is it just convention that bitfields on big endian systems
: >> : start from the most significant bit, and those on little endian systems
: >> : start from the least significant bit?  (My thinking is that endianness
: >> : usually refers to byte ordering and not so much bit ordering.)
: >>
: >> This is a convention that goes back a very long ways.  It was this way
: >> in the mid 1980's, and has remained true through today.  I've
: >> personally observed this to be the case on many different MIPS
: >> compilers, ARM compilers and SPARC compilers over the years.
: >
: > I'm fairly sure I've seen targets that use other bitfield orderings, though I 
: > can't remember offhand what they were.
: 
: Bi-endian targets are examples of this.  The bitfield ordering is normally
: independent of the selected byte order.  For example, big-endian MIPS has
: little endian bit order.

Except that compilers use the convention that was described above.
Big endian MIPS definitely uses a different bit ordering for C bit
fields than little endian MIPS.  This is true for compilers from SGI,
DEC and GNU and NetBSD, FreeBSD, Linux, Ultrix, OSF, and IRIX.  All of
them use the following, or variants for, say, the IP header:

struct ip {
#if BYTE_ORDER == LITTLE_ENDIAN
        unsigned int ip_hl:4,           /* header length */
                     ip_v:4;            /* version */
#endif
#if BYTE_ORDER == BIG_ENDIAN
        unsigned int ip_v:4,            /* version */
                     ip_hl:4;           /* header length */
#endif
...

Warner