powerpc gcc strange assembler for bitfields

[Eljay Love-Jensen]

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