Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!vrdxhq!bms-at!stuart From: stuart@bms-at.UUCP (Stuart D. Gathman) Newsgroups: comp.lang.c Subject: Re: bit-field pointers / arrays Message-ID: <321@bms-at.UUCP> Date: Tue, 16-Dec-86 00:03:15 EST Article-I.D.: bms-at.321 Posted: Tue Dec 16 00:03:15 1986 Date-Received: Wed, 17-Dec-86 07:16:51 EST References: <2937@bu-cs.BU.EDU> Organization: Business Management Systems, Inc., Fairfax, VA Lines: 73 Summary: A good argument, but let me add . . . In article <2937@bu-cs.BU.EDU>, bzs@bu-cs.BU.EDU (Barry Shein) writes: [ discussion of bit-fields in various languages deleted ] > 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. Unfortunately, a set of macros cannot use hardware bit-field instructions. Here is a list of processors which I know to have bit-field instructions that I can't get at from 'C': NEC V20, V30 M68000 & family PDP-11 (From previous posting) DEC-10, 20 VAX ??? Here are processors which do not: 8088 & kin other 8-bits: 6502 8080 etc ??? My point is that 'C' is efficient because is allows access to most common processor features through the compiler. 'C' is flexible because I/O and non-standard hardware features are handled through libraries. We are reaching the point where bit-fields are a common hardware feature. > Making bitfields full-blown objects in C would probably be a major > headache for compiler implementors and, I would guess, a never-ending I didn't have any trouble creating the macros mentioned earlier. Therefore it could not be *that* difficult. My complaint is that the macros do not utilize the hardware bitfield instructions. If your everyday optimizing compiler can figure out when to use these from a mess of shifts and masks, then I'll be satisfied. I think that bitfield arrays might be the easier approach, however. A situation similar to this is signed division. You would gag if you saw the code required to accomplish an unsigned multiply or divide on our Series/1 processor; the processor supports signed arithmetic only. Nevertheless, a 'C' compiler can code all that stuff for me so that I don't have to worry about the hardware deficiencies. I am glad that 'C' supports unsigned arithmetic; many programs would be a mess of macros otherwise! Most processors support unsigned multiply and divide, that is why 'unsigned' is part of 'C' (as opposed to a macro library). 'C' restricts itself to specifying lowlevel processor functions. All other tasks are left to data-types and libraries. Bit-fields are a low-level processor function. Hardware vector units can be handled efficiently via function calls. Bit operations are too small for that; a macro (with shifts and masks) would probably be faster! [ plug for overloaded operators deleted ] I agree heartily! I can hardly wait till I can code: complex a,b; . . . a += b; And: float x; x ^= 5; /* raise x to the 5'th power */ Plus, how about some APL like code using those vector libraries and nice readable operators? -- Stuart D. Gathman <..!seismo!dgis!bms-at!stuart>