bit-field pointers / arrays

Kenneth R. Ballou ballou at brahms
Fri Dec 12 08:31:50 AEST 1986


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
>
>or even:
>
>        unsigned pixelarr[640]:4
>
>for a line of EGA pixels.
>
>Bitfield pointers would have wildly different  formats  depending
>on the processor, of course.
>
>For 68020, it might be 6 bytes.  An address  followed  by  offset
>and  width in each of two bytes.  This would be loaded into three
>registers for use with the bit field processor instructions.

	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?  Two possibilities come to mind:

	1) Implementors do somehow kludge this.  Besides screwing up pointer
format, this causes a lot of code to be generated to emulate your bitfield
instructions.

	2) Implementors do not kludge this.  Now you are stuck with a bunch
of non-portable code.

	Look, it's bad enough that there are those who claim C is just
symbolic PDP-11 assembly language.  Why are you trying to turn it into
symbolic 68020 assembly language?

	Please, please, *PLEASE* remember the philosophy of C is to provide
a small, low-level language which would nonetheless put a lot of power in
the hands of the programmer (and also the other side of the coin, a responsi-
bility to code in a halfway decent style to keep this power from making a
total mess).   As a result, C can be made to run on almost anything.  If you
want a fine example of language design by committee, look at ADA.  It is a
fine language, but also note how difficult it is to implement a compiler and
have it validated.
--------
Kenneth R. Ballou			ARPA:  ballou at brahms
Department of Mathematics		UUCP:  ...!ucbvax!brahms!ballou
University of California
Berkeley, California  94720



More information about the Comp.lang.c mailing list