🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #21382

Re: Register usage

#21382
From: Stan Lackey
Date: Wed, 31 May 1989 21:49
45 lines
2952 bytes
In article <18965@cup.portal.com> bcase@cup.portal.com (Brian bcase Case) writes:
>For the implementations to come, including
>superscalar stuff, the issues will be the complexity of implementation and
>the cost (read:  people) of realizing that implementation.  This is where
>CISCs, I believe, will faulter.  One of the great advantages of RISCs is 
>that they are conceptually easier to implement.

In order to go superscalar, future RISC chips will end up having new,
incompatibile architectures.  I make this statement because I understand
the difficulty of the alternative, which is the execution of several
existing-architecture instructions concurrently.

I strongly suspect the RISC guys are, as we speak, analyzing stuff like:
 What kind of sequences frequently show up
 How to handle register dependencies and overutilized facilities
 Should totally independent instr's go in parallel only, or can dependent
   ones be issued and then pipelined (load to r0 followed by add to r0)

Let me guess what they're finding.  Correct me if I'm wrong.

 Load/store followed by increment/decr of the address is common.
 Load followed by dependent use of the data is common.
 Decrement of register, followed by test (compare or just zero), followed
   by branch, is common.
 Addition to register followed by its use as an address.
 Bunch of loads in a row, bunch of stores in a row.
[I could probably think of more with more time.]

Look familiar?  This prompted my first reaction when RISC started
getting popular: Where do they go from here? Yes, it's an interesting
technology opportunity.  But I'd rather implement the next generation
machines as CISC's rather than RISC's, IF I HAVE TO STAY INSTRUCTION
SET COMPATIBLE.  In other words, I think that when they learn how to
implement a fast CISC, it will go faster than the same-technology
RISC.  Why?  Because for the RISC to keep up, it will have to execute
an average of two instructions per cycle, and one instruction is a lot
easier to implement than two, even with auto-increment addressing.

Of course, there is always the possibility to do what they did the
first time: come out with a new architecture that matches the
technology window exactly.  Note recent product announcements: this
just keeps happening!  It's just that when you do this, expect a
limited lifetime of the architecture.

-Stan  [Disclaimer:  Do I have an opinion yet?]
Technical Details
Message-ID: <40718@bbn.COM>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!bbn!bbn.com!slackey
References: <259@mindlink.UUCP> <25382@ames.arc.nasa.gov> <m0fRx4x-0001fDC@mipon2.intel.com> <18965@cup.portal.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!bbn!bbn.com!slackey
From: slackey@bbn.com (Stan Lackey)
Newsgroups: comp.arch
Subject: Re: Register usage
Message-ID: <40718@bbn.COM>
Date: 31 May 89 21:49:57 GMT
References: <259@mindlink.UUCP> <25382@ames.arc.nasa.gov> <m0fRx4x-0001fDC@mipon2.intel.com> <18965@cup.portal.com>
Sender: news@bbn.COM
Reply-To: slackey@BBN.COM (Stan Lackey)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 45