Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!ames!ucbcad!ucbvax!cartan!brahms!ballou
From: ballou@brahms (Kenneth R. Ballou)
Newsgroups: comp.lang.c
Subject: Re: bit-field pointers / arrays
Message-ID: <534@cartan.Berkeley.EDU>
Date: Thu, 11-Dec-86 17:31:50 EST
Article-I.D.: cartan.534
Posted: Thu Dec 11 17:31:50 1986
Date-Received: Sat, 13-Dec-86 22:46:12 EST
References: <311@bms-at.UUCP>
Sender: daemon@cartan.Berkeley.EDU
Reply-To: ballou@brahms (Kenneth R. Ballou)
Organization: Math Dept. UC Berkeley
Lines: 57
Keywords: why not?

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
>
>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@brahms
Department of Mathematics		UUCP:  ...!ucbvax!brahms!ballou
University of California
Berkeley, California  94720