Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ncar!gatech!purdue!haven!ni.umd.edu!uc780.umd.edu!cs450a03
From: cs450a03@uc780.umd.edu
Newsgroups: comp.arch
Subject: RE: overview of HP-PA Bitfield insts.
Message-ID: <17APR91.22211654@uc780.umd.edu>
Date: 17 Apr 91 22:21:16 GMT
References: <1991Apr15.193425.3436@waikato.ac.nz> <zik.671779924@dec19> <51584@apple.Apple.COM> <1991Apr17.180036.3459@waikato.ac.nz> <3354@crdos1.crd.ge.COM>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: The University of Maryland University College
Lines: 29

Wm E Davidsen Jr    >
Lawrence D'Oliveiro >|

   [ talking about GIF compression ]
>| The only way I can see around this is to update the width value in
>| the instruction itself--using self-modifying code. ...  HP-PA is
>| one of those processors that will correctly invalidate its
>| instruction cache ...

> ... this is a good argument for an "execute" instruction, allowing
>you to build the instruction in a register ...

Oh, God... I'd LOVE a register based "execute" instruction.  It would
make my loop management code so elegant...  (just one instance of each
looping construct)

>  No matter how you do it you will slow things down to the point where
>it's unlikely to be faster than the mask and shift, unfortunatly.

Not Lawrence's example.  He only rarely needs to change the field
size.  That's why he didn't want to pay for a case statement inside
his loop.

Of course, he could just write, say, 8 instances of his compression
code (one for each field size).  Of course, then he'd probably take a
hit in cache performance, but he'd not be doing that "horrible self
modifying code stuff" :-/

Raul Rockwell