Path: utzoo!attcan!uunet!husc6!uwvax!tank!nic.MR.NET!shamash!nis!ems!srcsip!shankar
From: shankar@src.honeywell.COM (Son of Knuth)
Newsgroups: comp.arch
Subject: Re: A simple question on RISC
Message-ID: <12369@srcsip.UUCP>
Date: 22 Nov 88 18:42:43 GMT
References: <6544@xanth.cs.odu.edu> <75577@sun.uucp> <1618@imagine.PAWL.RPI.EDU> <419@augean.OZ> <392@ksr.UUCP> <	<7723@aw.sei.cmu.edu>> <oXV-=Wy00V4109jmdK@andrew.cmu.edu> <11562@cup.portal.com>
Reply-To: shankar@wabasha.UUCP (Son of Knuth)
Organization: Honeywell Systems & Research Center, Camden, MN
Lines: 27

In article <11562@cup.portal.com> bcase@cup.portal.com (Brian bcase Case) writes:
>>        mov     lower,i
>>        bra     entry
>>body    foo
>>        add     step,i
>>entry   cmp     i,upper
>>        bge     body
>>
>>Statically, same number of instructions; dynamically, less except in the
>>zero-trip case.  But look, the add, compare, and branch are consecutive.
>
>Ok, but notice the label in the middle of the add-compare-branch sequence?
>I don't think it is possible to specify the ACB instruction in a version
>that has a branch destination in the middle!  This is one of the points of
>RISC:  Hey, *I'M* the compiler, let *me* decide on the semantics of
>instruction sequences.

But this can be transformed into:
          bra    entry
body      foo
          acb    step,i,upper,body  (or whatever the ACB operands are)
entry     cmp    i,upper
          bge body

This doesn't justify the ACB instruction - but it does point out its
usefulness in the above example, assuming it doesn't take too many
microcode cycles.