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