[Tinyos-devel] TinyOS-2.x platform independent types?

[David Gay]

On 9/8/06, Matti Öhman <mohman at cc.hut.fi> wrote:
>   I did not consider the implications of mixing bit-fields of different
> endianness. However, that is not what I am proposing here. I think that is
> should be possible to use either little-endian or big-endian bit-fields -
> not both at the same time.
>
>   Currently it is possible to mix little-endian and big-endian types (not
> bit-fields) in the same structure:
>
> nx_struct {
>    nx_uint16_t a;
>    nxle_uint16_t b;
> }
>
>   which is laid out as:
>
> [a8a9a10a11a12a13a14a15][a0a1a2a3a4a5a6a7] ...
> [b0b1b2b3b4b5b6b7][b8b9b10b11b12b13b14b15]
>
>   Mixing little-endian and big-endian types this way seems unambiguous and
> easy to implement, but it still feels like a bad idea.
>
>   Is anyone using this feature?
>
>
>   It might be more appropriate to have separate structures for
> little-endian and big-endian bit-fields:
>
> nx_struct {
>    nx_uint8_t a:4;
>    nx_uint8_t b:4;
> }
>
> nxle_struct {
>    nxle_uint8_t a:4;
>    nxle_uint8_t b:4;
> }
>
>   How does this sound?

It may avoid users doing silly things, but it doesn't bring any real
benefit (I like the 2nd suggestion below better ;-))

>   Currently it is possible to write, say:
>
> nx_struct {
>    nx_uint16_t a:12;
>    nxle_uint16_t b;
>    nx_uint8_t c:4;
> }
>
>   and get some mysterious behaviour ("holes"):
>
> [a4a5a6a7a8a9a10a11][()()()()a0a1a2a3][b0b1b2b3b4b5b6b7] ...
> [b8b9b10b11b12b13b14b15][()()()()c0c1c2c3]

Actually there's nothing very surprising here. The holes are due to
the presence of a bitfield that doesn't fill a byte, followed by a
non-bitfield type/the end of the struct (i.e., b could be nx_uint16_t
and the holes would be the same).

>   Garbage in, garbage out, but this is the right way of doing it: as b is
> an ordinary field (not a bit-field) it is possible to take its address
> which means that it has to be aligned to a byte boundary. The following
> structure could be laid out in the same way by aligning adjacent
> bit-fields with different endianness at byte boundaries:
>
> nx_struct {
>    nx_uint16_t a:12;
>    nxle_uint16_t b:14;
>    nx_uint8_t c:4;
> }
>
>   the structure is terrible and so is the layout:
>
> [a4a5a6a7a8a9a10a11][()()()()a0a1a2a3][b0b1b2b3b4b5b6b7] ...
> [b8b9b10b11b12b13()()][()()()()c0c1c2c3]

But at least it has a nice consistent story :-) If I get the time,
this may show up in the next release of nesC...

David Gay