rcm (04/28/83)
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
gnu (04/29/83)
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