Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!vrdxhq!bms-at!stuart From: stuart@bms-at.UUCP (Stuart D. Gathman) Newsgroups: comp.lang.c Subject: Re: bit-field pointers / arrays Message-ID: <318@bms-at.UUCP> Date: Sun, 14-Dec-86 00:14:33 EST Article-I.D.: bms-at.318 Posted: Sun Dec 14 00:14:33 1986 Date-Received: Tue, 16-Dec-86 01:02:38 EST References: <311@bms-at.UUCP> <534@cartan.Berkeley.EDU> Organization: Business Management Systems, Inc., Fairfax, VA Lines: 42 Keywords: why not? Summary: Unjustified flame. In article <534@cartan.Berkeley.EDU>, ballou@brahms (Kenneth R. Ballou) writes: > In article <311@bms-at.UUCP> stuart@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>