bit-field pointers / arrays

[Barry Shein]

What is really being proposed here is a possible code-generation
methodology for bit-level addresses more than an extension of C,
although the proposer alludes to some of that.

Bit pointers etc (or, perhaps better put, variable size byte pointers
where bytes may be any number of bits from 1..wordsize) are well
defined for the PDP-10 architecture, very similar to this proposal (a
two word pointer/struct with offset, byte-size, word-pointer.)

Another approach which perhaps does a better job of showing how to
make arbitrary sized bitfields a full language object can be found in
PL/I where one could define the number of bits in an integer:

	declare foo,goo fixed binary (4);

declares foo and goo to be a 4-bit binary objects which will be
manipulated correctly by various operators (eg. foo+goo will be a
signed result with magnitude +- 7 [3 bits.], unsigned can be handled
as well.) Code will be automatically generated to use the architecture
to accomplish this (be it bit level instructions or lots of ands and
shifts, whatever, that's the compiler writer's problem.)

One could accomplish all this in C without much benefit from the
language or code generator by use of a set of macros or subroutines.

Making bitfields full-blown objects in C would probably be a major
headache for compiler implementors and, I would guess, a never-ending
source of compiler bugs and flames (eg. how do you interpret a one-bit
signed quantity? etc etc.) Before wishing for it, look at the code
generated by a PL/I compiler to manage this type of thing, you'll be
happier with what you have now (the only thing worse than not having
bitfields as full-blown types is having bitfields as full-blown types.)

So, PL/I and Simula come up as objects of nostalgia. Let's not try to
turn C into an object of nostalgia also. Certainly in the case of PL/1
it was precisely all these zillion (+- 10) "features" that caused the
ultimate demise of the language. It is nearly impossible (no, not
nearly, it is impossible...) to understand PL/1's semantics (lessee, I
add a fixed decimal (4,3) to a fixed binary (17) and then multiply by
an array of numeric char strings and suppress the on conversion...  hmm,
that should yield an intermediate result of, well, hmmm ...)

I think we'd be better off thinking about methods to better handle
abstract data types and overloaded operators (a la languages like
ADA and ALGOL68) and thus leave their interpretation in the hands
of the programmer (and his/her real needs) rather than just make a
list of data types which are sometimes useful and try to squeeze
them into C somehow. I believe extensibility is, in the long run,
more useful than specific extensions.

	-Barry Shein, Boston University