bit-field pointers / arrays

[Gregory Smith]

In article <534 at cartan.Berkeley.EDU> ballou at brahms (Kenneth R. Ballou) writes:
>In article <311 at bms-at.UUCP> stuart at bms-at.UUCP (Stuart D. Gathman) writes:
>>It  has  been  said  that  bit-field  arrays  are   intrinsically
>>impossible in 'C' because there can be no pointers to bit-fields.
>>
>>There is no special reason why there cannot be a type like:
>>
>>        unsigned *bitptr:1
>>
>>which would likely be bigger than a 'char *'.  Then we could also
>>declare:
>>
>>        unsigned bitarr[5000]:1

>	Oh, please, here we go again with someone else who wants to redefine
>C because he wants to take advantage of very specific features of his
>machine/environment!  Big deal, so you can do this in a straightforward manner
>on your 68020.  I'm just thrilled to pieces for you!  And what happens when
>trying to implement C on a machine which doesn't have your spiffy handy-dandy
>bitfield instructions? 

Mr Ballou's point is well taken, but I have been thinking about this
same problem as it applies to the Texas Instruments 34010. This is a
graphics processor, and it is definitely powerful enough to run C.
However, it is crying out for bitfield addresses and arrays of bitfields;
in fact a 34010 pointer is a bit pointer; to make a char* point to
the next char, the code would add 8 to the bit pattern in the char *.
Furthermore, there are no alignment requirements, and data items of
any size may be read and written.

My question is this: how do you support this through extensions to C?
( I wouldn't expect to port code from a 34010 to anything else).
Writing assembler subtroutines to do the work is obviously a big lose.
There are two fundamental problems:

	(1) how do you declare, say, a 6-bit data type?
	(2) how does sizeof work?

(1) It must be possible to declare signed and unsigned int types,
and specify the number of bits. I'm not sure I like

	unsigned bitarray[10]:3;

since the :3 really should be part of the type-specifier, in order
to allow typedefs to work consistently.

I would suggest
	unsigned bits:3 bitarray[20];

Where the bits keyword is always followed by ': <constant>'. A series
of keywords bit1, bit2.. could be used, but then it would be harder
to parameterize the widths ( and besides you can always typedef bits:2 bit2
if you want that).

As for (2), I would redefine sizeof to return the number of bits in
an object. this gives sizeof(char==8), sacrificing a lot of portability
to Real C, but given the nature of the beast, I wouldn't expect to be
porting a lot of code to it..

Has somebody already implemented such a compiler? how were these problems
dealt with?

-- 
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg
Have vAX, will hack...