Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!waikato.ac.nz!ldo From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) Newsgroups: comp.arch Subject: Re: overview of HP-PA Bitfield insts. Message-ID: <1991Apr17.180036.3459@waikato.ac.nz> Date: 17 Apr 91 18:00:36 +1200 References: <1991Apr15.193425.3436@waikato.ac.nz> <51584@apple.Apple.COM> Organization: University of Waikato, Hamilton, New Zealand Lines: 30 In article <51584@apple.Apple.COM>, baum@apple.com (Allen Baum) gives an overview of the HP-PA bitfield instructions. He mentions that there are versions which take a variable value for the field offset, but none which take a variable value for the length: "We didn't see it happening enough to put it in, and in the rare cases it occurs, a case branch can be used." Unfortunately, in the GIF compression/decompression example which inspired me to start this discussion, an instruction which could handle variable-length bitfields would work very well indeed. This is because the symbol size grows, as more symbols are added to the translation table. It doesn't grow very rapidly (it goes to 10 bits once you've defined 512 symbols, to 11 bits when you've got 1024, and so on), but I still wouldn't like to see a case branch taking up execution time within the compression/decompression loop. The only way I can see around this is to update the width value in the instruction itself--using self-modifying code. Hmmm, I seem to recall from another discussion some time ago that the HP-PA is one of those processors that will correctly invalidate its instruction cache if you do any writes to program code in memory. So this should work quite nicely. Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 To someone with a hammer and a screwdriver, every problem looks like a nail with threads.