Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!olivea!bbn.com!pplacewa
From: pplacewa@bbn.com (Paul W Placeway)
Newsgroups: comp.arch
Subject: Re: Loop instructions
Message-ID: <63942@bbn.BBN.COM>
Date: 29 Apr 91 23:07:12 GMT
References: <1991Apr16.152438.3445@waikato.ac.nz> <12739@pt.cs.cmu.edu> <41612@cup.portal.com>
Sender: news@bbn.com
Lines: 37

ts@cup.portal.com (Tim W Smith) writes:

< Chris Torek says:
< > However, it turns out that on the 68020 it is almost invariably faster
< > to avoid DBcc anyway (bcopy, for instance, should be unrolled).  Score

< If you unroll too far, don't you start to miss on the instruction
< cache?  The optimum seems to be unrolled enough to lower loop overhead
< but rolled enough to fit the loop in the cache.

After hacking too many DSP things, all I have to say about loop
unrolling is that it's a good technique to make up for a bad
architecture.

What I want in my processor is a zero-overhead-per-loop down-counting
loop instruction.  The TMS320 series, and Motorola DSP 56000 and 96000
have had this sort of thing for quite a while.  For those of you who
happen to be unfamilar, the idea is that the PC addressing hardware
has a loop beginning, end, and count register and the hardware does a
decrement-branch-nonzero when the PC == end-of-loop, resetting it to
beginning-of-loop, while in the instruction fetch stage.

The 320C30 also has a repeat-single mode which just does the next
instruction N times.  Unfortunately the processor also *ignores*
interrupts during the loop, so I can't use it, but if it wasn't broken
in that small way it would be very useful indeed.

Note that this could also be done in a bunch of different ways, like
for instance in a superscaler just doing a DBNZ in parallel with the
previous instruction.  I don't care much how it actually works, but it
is quite fun to have things like a vector sum or vector-vector add or
an inline bcopy() that run at one instruction per operation.

Now if only the "real" processor in my workstation could do such
things.

		-- Paul Placeway <pplaceway@bbn.com>