Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!rpi!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.arch
Subject: Re: Bitfield instructions--a good idea?
Message-ID: <3339@crdos1.crd.ge.COM>
Date: 15 Apr 91 12:56:27 GMT
References: <1991Apr15.193425.3436@waikato.ac.nz>
Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen)
Organization: GE Corp R&D Center, Schenectady NY
Lines: 26

In article <1991Apr15.193425.3436@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:

| The result? I sped up the code by more than 20%. I know the
| compiler I was using generated pretty lousy code, but it allowed
| the insertion of in-line machine code, which was how I was
| fine-tuning the time-consuming parts.
| 
| Do other people find these instructions useful?

  I have two more questions, which I think would be less
controversial...

 a) for machines which have to do a lot of this would a bitfield
    coprocessor make sense? I ballpark guess a 5:1 speedup of those
    instructions. 

 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)
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
        "Most of the VAX instructions are in microcode,
         but halt and no-op are in hardware for efficiency"