From: Andreas Schwab <schwab@suse.de>
Subject: Re: [Qemu-devel] [PATCH] pcnet32 driver change, please test
References: <20070302200949.GD27636@networkno.de>
	<20070302231450.GA6741@miranda.arrow>
	<20070302.175333.1622572844.imp@bsdimp.com>
	<200703030101.56126.paul@codesourcery.com>
Date: Sat, 03 Mar 2007 11:25:13 +0100
In-Reply-To: <200703030101.56126.paul@codesourcery.com> (Paul Brook's message
	of "Sat, 3 Mar 2007 01:01:55 +0000")
Message-ID: <jemz2uvd2u.fsf@sykes.suse.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Reply-To: qemu-devel@nongnu.org
To: qemu-devel@nongnu.org

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 syst=
ems
>> : start from the most significant bit, and those on little endian syst=
ems
>> : start from the least significant bit?  (My thinking is that endianne=
ss
>> : 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, th=
ough I=20
> can't remember offhand what they were.

Bi-endian targets are examples of this.  The bitfield ordering is normall=
y
independent of the selected byte order.  For example, big-endian MIPS has
little endian bit order.

Andreas.

--=20
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstra=DFe 5, 90409 N=FCrnberg, Germany
PGP key fingerprint =3D 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED=
5
"And now for something completely different."