Hi,
Thank you all for your help and thoughts.
I'm just ploughing through all my legacy code changing all the bit field
accesses. It is the right thing to do.
Bit fields are really nice when accessing bits in registers in
peripherals but I can see that their implementation can be somewhat
random.
I do have to say though that defining an element in a structure as
16bits should result in the compiler doing (architecture allowing) 16bit
operations on that memory address. Perhaps doing smaller (and maybe more
efficient) operations/accesses is something that should be part of the
optimiser? Just my view on things...
Thanks again
Pete
On Thu, 2005-04-21 at 06:56 -0500, Eljay Love-Jensen wrote:
> Hi Peter,
>
> Are you using C or C++?
>
> My recommendation -- which is based on low-level interfacing to 3270 EBus hardware on DEC Alpha RISC architecture machines; which (early Alpha architectures) does not support byte-memory read/write memory access, and wreaks havoc on byte-oriented memory mapped hardware (including bitfield byte oriented hardware registers) without minding one's p's and q's...
>
> #1 Don't use bitfields. Bitfields in C (and legacy to C++) were not well specified in the language, in the sense that they are an afterthought, and a begrudging afterthought at that. (In my opinion.)
>
> #2 Did you know that all bitfields are supposed to be natural word length of the architecture -- i.e., either "signed int" or "unsigned int"? Is your memory architecture such that VUINT16 maps to one of those? Not long, not short, not char. If not (and it works as you are expecting), then you are facing a compiler extension.
>
> #3 Did you know that the big-endian-vs-little-endian packing of bitfields is platform (compiler + OS) specific? And that behind-the-scenes interstitial bitfield padding of specified bitfields may occur and is platform specific?
>
> #4 In C (as Nathan already mentioned), create accessor and mutator functions. You will be in control.
> VUINT16 VReadStop(TPUMCR* p); // accessor
> void VWriteStop(TPUMCR* p, VUINT16 value); // mutator
>
> #5 In C++, create a class with accessor and mutator functions. In C++, it will be the natural way to use the object.
> class TPUMCR
> {
> VUINT16 R;
> public:
> operator VStop () const; // accessor
> void operator = (VStop value); // mutator
> };
>
> Note: my druthers is that the operator= is a void-return when used as a subfield mutator, since the question "Should it return TPUMCR& or VStop?" is avoided, and as a void-return the compiler will point out if you make an inadvertent mistake. Also, Objective-C experience with proxy objects indicates that's a defensible idiom.
>
> HTH,
> --Eljay
>
