🚀 go-pugleaf

dwayne@dwayneb.b17d.ingr.com (Dwayne A. Blumenberg) writes:

>I've noticed lately that some recent IBM code uses
>the sequence:

>    L     Rx,AREA
>    LTR   Rx,Rx
>    BNZ   SOMEWHERE

>and I was wondering if

>    ICM   Rx,15,AREA
>    BNZ   SOMEWHERE

>would be faster?  It looks to me like the two code segments
>would produce identical results (ignoring for the moment that
>the LOAD instruction could take an index register, and that
>ICM wasn't available on the 360, and that LOAD on a 360 could
>cause a specification exception).

Sounds right.

>I'm sure that LTR is very fast, but is L + LTR faster than
>ICM?  What, if any, advantages does the L + LTR sequence offer
>above ICM?

In a pipelined implementation, unless ICM 15 is implemented to be equivalent to
L/LTR (which would require decoding ICM 15 differently than the general case of
ICM by skipping masking of the loaded result before a compare), which I find
unlikely, it would seem reasonable that the L/LTR would execute faster because
the LTR would execute immediately after the result of the L is available (via
bypass circuitry).  In defense of ICM 15: it does save two bytes :-).

In support of my interpretation... there was a thread recently in comp.arch on
claims that use of RISC-y ISA subsets on CISC processors can trade somewhat
increased code space for much higher performance.

--
John R. Grout
University of Illinois, Urbana-Champaign
Center for Supercomputing Research and Development

    INTERNET: j-grout@uiuc.edu