Re: [boost] [bitfield] Initial bitfield proposal availableinthevault

From: Andy Little (andy_at_[hidden])
Date: 2006-03-07 12:43:14

"Martin Bonner"  wrote
> Andy Little wrote
>> "Martin Bonner" <martin.bonner_at_[hidden]> wrote in message
>> news:D997BF79D1E92C4793B7FCC04B4F90A51D79B6_at_pigeon.pi.local...
>>> ----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).
>>
>> Though in practise you can use:
>>
>> BOOST_STATIC_ASSERT(sizeof(u) == sizeof(unsigned char))
>
> My point was exactly that you CANNOT use that.  (On a certain class of
> machine).

Why not?. Will it a) compile but be incorrect or b) not compile but be incorrect 
or c) not compile but be correct?
How do you store an unsigned char then? (And whatever way that is just pretend 
to the hardware that the struct is an 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.
>>
>> I dont see why the size of a pointer to a struct affects the size of
>> a struct which in the case of an empty struct is often 1 byte?
>
> I don't think you have understood what a word addressed machine is!
>
> On most modern archictectures there are 8 bits stored at (for example)
> 0x100 and another 8 bits at 0x101.  The 32 bits at 0x100 cover 0x100,
> 0x101, 0x102, and 0x103.
>
> On a word addressed machine, there may be 36 bits stored at 02000 and
> another (different) 36 bits stored at 02001.  A simple 36-bit pointer
> can address individual words, but not sub-units within those words.  To
> address individual bytes, you need a double-word pointer.  One word
> identifies the word, and a few bits within the second word identifies
> which byte you are addressing.
>
> On such a machine, it makes sense for an empty struct to occupy a whole
> word (which is four nine-bit bytes), so that a pointer to struct can
> (always) be a single word pointer.

Sounds like there is a choice. Either make unsigned char 36 bits and use a small 
pointer or make unsigned char 9 bits and use a large pointer. I dont know 
whether C++ will allow both? It reminds me of the old Microchip PIC architecture 
though. Last I looked they were working to make their hardware compatible with C 
FWIW  and just increasing the number of address lines, because they were 
previously so difficult to deal with, with the separate extra bits in an address 
and so on (though that was a kind of paged memory IIRC).  IOW in their case they 
realised the downside of the idea as I understand it and moved to one drop 
linear addressing for later designs.

Maybe I have got the wrong end of the proverbial stick again though ?

regards
Andy Little