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
