From: utzoo!decvax!harpo!seismo!rocheste!ritcv!tropix!rcm
Newsgroups: net.lang.c,net.unix-wizards
Title: bitfield question
Article-I.D.: tropix.125
Posted: Wed Apr 27 18:27:34 1983
Received: Fri Apr 29 21:59:27 1983
References: cdi.170

The example was designed to show the packing of an array of bitfields,
and the (unexpected) discovery that the bitfields were packed into
ints (which were 32 bits in the VAX) and thus not very tightly packed.
This came up here when we went from a 68k c compiler with 32bit ints
to one with 16bit ints (pcc).  We had to design the interface to accommodate
the 32bit ints, even though only bytes were needed.  Fill bits were
added to acommodate the allignment on the 16bit int version of the
individual structure entry to make the code work again.  We also found
that the order of bits was reversed between the compilers, so we
had to invert the order of the bits in the  field.  This is apparently
true in the 11 and vax implementations.  This caused quite a bit of
flack here, and caused us to look carefully into K&R to see just what is right.
Hence:
from p 137,

"A field is a set of ajacent bits within a single int." ...

from p 138,

"...fields are assigned left to right on some machines and right to
left on others, reflecting the nature of the different hardware."

but in the Appendix, p196,

"Fields are assigned right to left on the PDP-11, left to right on
other machines."

My question is, How dows this work on the new micros, especially
the 68020 (where left to right fits the new bitfield operations nicely,
but right to left fits the old bit set and clear instructions) and
the 16k (where objects are addressed from the low order byte.)

In retrospect, the familiar masking and a few well considered macros
would have made us much less susceptable to these portability questions,
and made the code more efficient, besides.

						Bob Moore
						Tropel/GCA
						tropix