Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ll-xn!mit-eddie!bu-cs!bzs From: bzs@bu-cs.BU.EDU (Barry Shein) Newsgroups: comp.lang.c Subject: Re: bit-field pointers / arrays Message-ID: <2937@bu-cs.BU.EDU> Date: Sun, 14-Dec-86 16:24:58 EST Article-I.D.: bu-cs.2937 Posted: Sun Dec 14 16:24:58 1986 Date-Received: Tue, 16-Dec-86 03:14:50 EST Organization: Boston U. Comp. Sci. Lines: 52 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