bit-field pointers / arrays
Stuart D. Gathman
stuart at bms-at.UUCP
Sun Dec 14 15:14:33 AEST 1986
In article <534 at cartan.Berkeley.EDU>, ballou at brahms (Kenneth R. Ballou) writes:
> In article <311 at bms-at.UUCP> stuart at bms-at.UUCP (Stuart D. Gathman) writes:
[ bitfield array proposal deleted, see parent article ]
> Oh, please, here we go again with someone else who wants to redefine
> C because he wants to take advantage of very specific features of his
> machine/environment! Big deal, so you can do this in a straightforward manner
> on your 68020. I'm just thrilled to pieces for you! And what happens when
> trying to implement C on a machine which doesn't have your spiffy handy-dandy
> bitfield instructions? Two possibilities come to mind:
[ etc, etc ]
As a matter of fact, we do not even have a 68020 machine. I was
merely giving an example for what I assumed was a popular
processor to illustrate the feasability. The NEC V20/V30 and the
VAX are other processors which I know for a fact have bit field
instructions. Processors that don't have such nifty instructions
generate lots of code; but ONLY when bitfields are used. This
happens already now when using bitfield in structures! Even
then, the compiler probably generates less code than if you did
it yourself using shifts and 'and's. Furthermore, the bitfield
code is a lot more portable than lots of shifts and logic with
the accompanying assumptions regarding byte size, etc. The EGA
application was just an EXAMPLE (and was labeled as such). The
primary portable application would be bit arrays.
The operators in the 'C' language were designed to relect
functions held in common across a wide range of processors. Many
hardware extensions can be handled conveniently via functions
(e.g. vector processors). Bit manipulation is something that
most modern processors can do efficiently with built in
instructions, and that any machine can do just as efficiently
with compiler generated code as with programmer specified shifts
and masks. It cannot however be handled well with functions.
Current 'C' *already* has bitfield support. I am merely throwing
out the idea of rounding out that support to allow arrays and
pointers as well.
--
Stuart D. Gathman <..!seismo!dgis!bms-at!stuart>
More information about the Comp.lang.c
mailing list