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