Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!greg
From: greg@utcsri.UUCP (Gregory Smith)
Newsgroups: comp.lang.c
Subject: Re: bit-field pointers / arrays
Message-ID: <3811@utcsri.UUCP>
Date: Fri, 19-Dec-86 14:31:19 EST
Article-I.D.: utcsri.3811
Posted: Fri Dec 19 14:31:19 1986
Date-Received: Fri, 19-Dec-86 23:22:36 EST
References: <2937@bu-cs.BU.EDU> <321@bms-at.UUCP>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Organization: CSRI, University of Toronto
Lines: 66
Summary: 

In article <321@bms-at.UUCP> stuart@bms-at.UUCP (Stuart D. Gathman) writes:
>	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':
...
>	VAX
...
>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.

Let's see:

main(){
	int a,b,c,d;
	register int x,y;
	x = (a>>13) & 15;	/* extract 4 bits */
	b |= 1<<y;		/* set a bit at variable position */
	c &= ~4; c |= y<<2;	/* insert unknown bit at fixed posn */
	d &=~0xf80; d|= y<<7;	/* insert 5 bits at fixed posn */
}
...
extzv	$13,$4,-4(fp),r11	|x = (a>>13) & 15; can't complain
ashl	r10,$1,r0		| 1<<y
bisl2	r0,-8(fp)		| b |= 1<<y
bicl2	$4,-12(fp)		| c ~= ~4
ashl	$2,r10,r0		| y<<2
bisl2	r0,-12(fp)		| c |= y<<2
bicl2	$3968,-16(fp)		| c &= ~0xf80
ashl	$7,r10,r0		| y<<7
bisl2	r0,-16(fp)		| d|=y<<7;

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).

Despite the difficulty, I would prefer that the compiler figures out
when to use these from the mess of shifts and masks, rather than
by adding new types to the language. For one thing, this method
will allow bitfield ops to be used for shifts & masks that were
not specifically intended to operate on bitfields.

If it is that difficult to determine when a bitfield op can be used,
we should be asking why microcode is being wasted on them. (I'm not
sure it is that difficult, and I don't think it is necessarily
wasted).

Note that this solution adds several pages of code to the code
generator only on machines with bitfield ops, while the other solution
adds zillions of semantics checks, and other extra stuff *throughout*
the compiler, to the compiler on *all* machines.

[ these viewpoints may seem contrary to my previous posting re the
  34010. That was a graphics processor, and I was talking about C
  extensions. Here I am talking about general-purpose programming
  where portability is important ]


-- 
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg
Have vAX, will hack...