Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP Path: utzoo!utcsri!greg From: greg@utcsri.UUCP (Gregory Smith) Newsgroups: comp.lang.c Subject: Re: bit-field pointers / arrays Message-ID: <3796@utcsri.UUCP> Date: Mon, 15-Dec-86 14:01:34 EST Article-I.D.: utcsri.3796 Posted: Mon Dec 15 14:01:34 1986 Date-Received: Tue, 16-Dec-86 19:43:15 EST References: <311@bms-at.UUCP> <534@cartan.Berkeley.EDU> Reply-To: greg@utcsri.UUCP (Gregory Smith) Organization: CSRI, University of Toronto Lines: 66 Keywords: why not? Summary: Almost-C on a 34010 In article <534@cartan.Berkeley.EDU> ballou@brahms (Kenneth R. Ballou) writes: >In article <311@bms-at.UUCP> stuart@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 ':'. 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...