Re: bitfields: types vs modes?

[DJ Delorie <dj at redhat dot com>]

> Can you provide example code?  I'm confused enough to believe
> that you *should* get this effect with PCC_BITFIELD_TYPE_MATTERS
> (modulo current bugs).

Imagine a device with four 8-bit registers followed by a 32-bit
register with an 8-bit field:

byte	status (read-only, clears after reading)
byte	control (read/write)
byte	tx buf (write only)
byte	rx buf (read only)
long	uart configuration
		divisor:8
		bits:3
		stop:1
		start:1
		reserved:3
		clock source:8
		pin_selection:8

so, you'd do this:

typedef struct {
  char status:8;
  char control:8;
  char tx:8;
  char rx:8;
  long divisor:8;
  long bits:3;
  long stop:1;
  long start:1;
  long reserved:3;
  long clock_source:8;
  long pin_selection:8;
} UartDev;

extern volatile UartDev uart1;

If you use SImode to access any of the first four registers, you may
end up clearing a status bit you haven't read yet.  If you use QImode
to write the divisor, you may end up clearing the other bits if gcc
doesn't drive the right values onto the bus.

With our current code, the mode for access for the above would either
always be QI or always be SI; there's no way to have QI for the first
four and SI for the rest.

The culprit is get_best_mode(), which doesn't know the C type of the
field.  PCC_BITFIELD_TYPE_MATTERS seems to only control layout, not
access.  Even if it did solve the type-v-mode problem, turning it on
would break ABI compatibility.