🚀 go-pugleaf

These are all questions/comments rather than bugs.  Is there a more
appropriate mailing list?

I'd like to see bitfields be efficient enough so that I could always use
them rather than doing manual packing/unpacking.  Unfortunately there are
still some big hits.

1) On the sparc bitfields seem to allocated in a big endian fashion.  There
is a competing concern in that the least significant 12 bits are faster to
access.  Its a little grotty to have to explicitly pad out the definition
so that important bits fall in the low 12 bits.

2) The compiler seems to always emit a read-modify-write for each
assignment to a bitfield.  When one has carefully aligned fields on word
boundaries it is possible to produce much better code when there are
successive assignments to all the fields in a word.  Eg

    typedef struct x {
      /* ... */
      signed int a	: 14;
      unsigned int b	:  6;
      unsigned int c	: 12;
    } HASH_ENTRY;

    struct x *p;

    p->a = aa;
    p->b = bb;
    p->c = cc;

The sequence of individual read-modify-writes takes 18 cycles on the
cypress sparc chip.  By taking advantage of the fact that the whole word is
being filled you can cut this in half.

3) Logical operations (bitwise and, xor, or) on a bitfield are done by
extracting the field, doing the operation and then reinserting the new
value.  Its possible to do these in place.  Eg

   struct flags {
     unsigned pad:31;
     unsigned turn:1;
   };

   struct flags f;

   f.turn ^= 1;

For this I see sparc code like:

	and %l0,1,%o0
	xor %o0,1,%o0
	and %l0,-2,%l0
	or %l0,%o0,%l0

It could be:

	xor %l1,1,%l1