Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!usc!henry.jpl.nasa.gov!elroy.jpl.nasa.gov!gryphon!scarter
From: scarter@gryphon.COM (Scott Carter)
Newsgroups: comp.arch
Subject: Autoincrement and RISCs (was: Re: the IBM 801, was ERISC???)
Message-ID: <22159@gryphon.COM>
Date: 12 Nov 89 21:00:46 GMT
References: <16190@vail.ICO.ISC.COM> <2393@gmu90x.UUCP> <1087@m3.mfci.UUCP> <1228@crdos1.crd.ge.COM> <1192@unify.UUCP> <30517@obiwan.mips.C <KERS.89Nov3084527@cdollin.hpl.hp.com>
Reply-To: scarter@gryphon.COM (Scott Carter)
Organization: McDonnell Douglas Electronic Systems, Huntington Beach, CA
Lines: 31


Our MD484 GaAs RISC had a capability along these lines:  Base-offset and
base-index addressing modes;  ALU result went to the operand pipe and the
usual writeback including bypass.  The memory pipes looked like two FIFOs
(read and write) addressed at a few specific register decodes.  There was
also some speculative bypassing of the O-cache to the ALU input.

In theory the scheme worked fairly well - with hand-coding we could get much
better performance for the codes we were interested in than we would get
from a Mips architecture at the same clock rate.  However, compiling for
the @#$%&! (compiler based on Chow's - no funding to really do the
compiler work at all well enough) just never came out right in terms of
making use of the architecture; half the time there was some obscure path
where the memory ref was still live and we couldn't figure out how to
weight re-issuing the read.  I still suspect (possibly in conjunction
with conventional load instructions) it could be a winner with a decent 
compiler.


The "decoupled load-store" also made it easy to gang the CPUs together
with some external address generators for a pseudo-SIMD processor, which was
one of the goals of the program.

Anybody know of any more recent compiler work that might be appropriate?

Thanks,

Scott Carter
(714)-896-3097

Opinions expressed herein are those of the author alone.