bit-field pointers / arrays

[Chris Torek]

In article <3811 at utcsri.UUCP> greg at utcsri.UUCP (Gregory Smith) writes:
[In response to the allegation that C compilers will not use bit
field instrucitons on Vaxen]

>	x = (a>>13) & 15;	/* extract 4 bits */

compiles to

>extzv	$13,$4,-4(fp),r11	|x = (a>>13) & 15; can't complain

but

>	b |= 1<<y;		/* set a bit at variable position */

becomes

>ashl	r10,$1,r0		| 1<<y
>bisl2	r0,-8(fp)		| b |= 1<<y

rather than `insv r10,$1,$1,-8(fp)' (if I got the argument order
right).

>The compiler used a bitfield op only in the first case. I guess the
>problem is that the other operations are not easily detectable as
>candidates for bitfield instructions, especially when written as
>two statements (I tried writing the last as d=(d&~0xf8) | (y<<7)
>but it didn't help).

The real problem is that insv `clears the condition codes'.  The
bitfield operands are all inserted by the peephole optimiser,
/lib/c2 (at least on a 4BSD Vax, which is what Greg appears to be
using).  There is a section of code in c21.c to use insv that is
commented out with a note to this effect.  c2 could still do the
job if it were a bit smarter, or if it had more help from the
compiler as to which expressions are done for condition codes.

C's existing bitfield support has been called `a botch and a blemish'
(if I recall correctly, this is from DMR himself).  Be that as it
may, any attempt to repair or replace the existing facility is
sufficent change that the language should not then be called `C'.
There are a number of problems with bitfields:  Are they signed?
Unsigned?  Can they span word boundaries?  Can they be larger than
a machine word?  (struct { int i:200; }; is illegal on all compilers
I have used.)  All of these questions must be answered, either with
`yes', `no', or `compiler dependent'; by the time you are done,
you have something that is either slow, insufficient, or unportable.
C opts for the last.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris at mimsy.umd.edu