On Thursday 28 February 2008 13:09, Michael Schnell wrote: > > Yes. That's what {$BIT_ORDER} would stand for (still, it would not > > change *byte* order). > > I don't understand this. I don't think the bit order within a byte is > to be considered changing.
Well, the question is, if the first bit in a record is the leftmost or the rightmost bit. It's a matter of interpretation. But as Jonas pointed out, the order of the bits may change depending on the endianess (assuming I didn't misunderstand him). > I would call the issue "byte-order" and (thus I'd prefer something > like {$BIT_PACKED_BYTE_ORDER} or {$BIT_PACKED_ENDIAN}. It's not byte order. If I declare: |bitpacked record | X : Byte; | Y : Byte; |end record; X will still be at the lowest address and Y will be at @X + 1. The issue arises when I say: |bitpacked record | X : Boolean; | Y : Boolean; | Z : Two_Bit_Enum; |end; Assuming, bit 0 is the LSB, does the compiler access bit 0 and 1 (low order first) for X and Y or does it choose bit 7 and 6 (high order first) then? And how would it interprete a specific value for Z? At least two interpretations are possible: X:7, Y:6, Z[5:4] or X:0, Y:1, Z[3:2] ASCII graphic: |X|Y|Z|Z|-|-|-|-| |-|-|-|-|Z|Z|Y|X| Ok, I guess, the issue with the enum is none, because the LSB is still at the right place on the data bus, no matter how you look at it. So forget that. ;) Of course, there are more nasty things like |bitpacked record | X : Boolean; | Y : Byte; |end; where a single value would cross the byte boundary... *headscratch* I guess, there's a reason, why endianess issues are not automatically handled by the compiler. :D Vinzent. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel