[fpc-devel] Freepascal in microcontrollers

[Vinzent Hoefler]

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.