From: Emile Cormier (emilecormier_at_[hidden])
Date: 2006-03-07 16:13:38
Martin Bonner wrote:
> ----Original Message----
> From: Emile Cormier
>
>> The bitfield mechanism relies on this assumption: Unions of
>> non-polymorphic, non-derived objects, having the exact same underlying
>> data member type, will have the same size as this underlying data
>> member type. I'm no language lawyer, so please let me know if this is
>> a safe and portable assumption.
>
> I'm not quite sure what you mean, but given:
> struct a { unsigned char ch; };
> struct b { unsigned char ch; };
> union u { a theA; b theB };
> then you are not guaranteed that sizeof(u) == sizeof(unsigned char).
>
> On word addressed machines (which /are/ still being built), it is almost
> certain that the minimum size for a struct is a complete word. This is
> because the C and C++ standards effectively promise that pointers to
> structs are all of the same size (the size of a pointer-to-struct does
> not depend on the contents of the struct). It is desirable that a
> pointer-to-struct be the smaller, cheaper-to-dereference pointer to word
> (rather than the larger more-expensive-to-dereference pointer to char),
> so the smallest struct has to occupy a whole word.
>
> HOWEVER, if your structures and unions are using unsigned char, why not
> just use "unsigned char *" instead? If you are using unsigned short (or
> longer types), then you are almost certain to be safe. It is not
> guaranteed by the standard; a compiler /can/ pad all structures to 256
> bits if it wants to, but in practise compilers don't.
>
>
I've just run some tests on an ARM platform (arm-elf-gcc), and sizeof(u)
from Martin's example above always returns 4 regardless of whether char,
short, or long are used. If I use the -fpack-struct option, then
sizeof(u) becomes 1/2/4 for char/short/long respectively.
On gcc x86, i get sizeof(u) = 1/2/4 for char/short/long without
-fpack-struct.
Martin is on to something about using pointers. The pointer already
"knows" how to access char/short/long integers. The disadvantage of
using pointers is their storage space and the indirection to the actual
data. For example, a system with 50 8-bit registers would require
50*sizeof(char*) bytes to store the pointers.
I'd prefer that the bitfield manipulate the data directly, so that, for
example:
union hardware_reg
{
bitfield<uint16_t, 4, 8> bf1;
};
hardware_reg a;
a.bf = val;
is equivalent to:
uint16_t a;
a = (a & 0xfff0) | ( (val & 0x000f) << 4 );
rather than:
uint16_t a;
uint16_t* p = &a;
*p = (*p & 0xfff0) | ( (val & 0x000f) << 4 );
I've got another way of doing bitfields up my sleeve that is not as
syntactically pretty as C++ bitfields, but may be much more portable.
I'll let you know when I've uploaded "version 2" to the Boost vault.