Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!pa.dec.com!decuac!grebyn!ckp
From: ckp@grebyn.com (Checkpoint Technologies)
Newsgroups: comp.arch
Subject: Re: Bitfield instructions--a good idea?
Message-ID: <1991Apr16.131322.11852@grebyn.com>
Date: 16 Apr 91 13:13:22 GMT
References: <1991Apr15.193425.3436@waikato.ac.nz> <3339@crdos1.crd.ge.COM>
Organization: Grebyn Timesharing
Lines: 35

In article <3339@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
> b) should the next version of ANSI/ISO C include a standard bit fiddle
>    library, and what should be in it. My thoughts:
>    - get/put bit(s) to/from a buffer
>	getbits(char * buf, int startbit, int nbits)
>    - read/write bits from a file
>	readbits(FILE * fp, char * buffer, int nbits)

  You can write any library routines you want for this, right now.

  I want bit field arrays: struct s { unsigned int bitflags :1 [4096]; };

  On the other hand, perhaps extending bit fields is less valuable than
allowing packed data objects.  Suppose, for example, the next C allows
the the following type to occupy 2 bits:

  typedef enum { zero=0, one, two, three } twobits;

  Then an array of 'twobits' would be packed tightly.  For compatibility,
a new qualifier would probably be in order:

  packed twobits tb[1024];

  A pointer to a bit field is possible; the language simply must
create a storage pointer plus a bit offset, so it would truly
be a different representation than for other pointers.  But you all
always knew that pointers to different types could have different
representations, didn't you???

  But then, all this stuff belong in alt.lang.cfutures...
-- 
First comes the logo: C H E C K P O I N T  T E C H N O L O G I E S      / /  
                                                ckp@grebyn.com      \\ / /    
Then, the disclaimer:  All expressed opinions are, indeed, opinions. \  / o
Now for the witty part:    I'm pink, therefore, I'm spam!             \/