bit-field pointers / arrays
Stuart D. Gathman
stuart at bms-at.UUCP
Tue Dec 16 15:03:15 AEST 1986
In article <2937 at bu-cs.BU.EDU>, bzs at 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>
More information about the Comp.lang.c
mailing list