bitfield question

utzoo!decvax!decwrl!sun!gnu utzoo!decvax!decwrl!sun!gnu
Fri Apr 29 04:01:55 AEST 1983


	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.)

Well, since the 68020 only exists on paper, but is software compatible
with 68000's and 68010's and 68008's, the answer is: the same way as on a
68000.  Ours (and all I know) do it left to right.

On the 16k, I suspect right to left due to little-endian-ness.  I'd guess
that K&R singles out the 11 because at the time it was the only little-
endian Unix machine.

It doesn't really matter which way you assign them; since there are
no facilities in C to subscript bitfields, the bit numbers in the instructions
are all calculated at compile time anyway and can be forwards or backwards
from what the programmer sees.

	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.

In retrospect, the introduction of bit fields did not solve the problem
it was designed to solve -- portability of bit-fiddling.  This became
especially obvious when incompatible machines were networked and
actually had to read and write each others' bitfields.  Has anyone (eg,
DMR or USG) considered improvement, phased desupport, and/or replacement
a la =+ ?

	John Gilmore, Sun Microsystems



More information about the Comp.lang.c mailing list