Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!think!bloom-beacon!bu-cs!purdue!decwrl!sun!aeras!elxsi!beatnix!rw
From: rw@beatnix.UUCP (Russell Williams)
Newsgroups: comp.arch
Subject: Re: 64 bits
Message-ID: <1838@elxsi.UUCP>
Date: 3 Jan 89 19:15:42 GMT
References: <28200249@mcdurb> <451@babbage.acc.virginia.edu> <1951@scolex> <1723@elxsi.UUCP> <13096@cup.portal.com>
Sender: news@elxsi.UUCP
Reply-To: rw@beatnix.UUCP (Russell Williams)
Organization: ELXSI Super Computers, San Jose
Lines: 59

In article <13096@cup.portal.com> bcase@cup.portal.com (Brian bcase Case) writes:
>>The (ELXSI) instruction set is not risc, but is
>>much closer to a risc than to a VAX -- typical cpi for our latest CPU (which
>>is made out of 2 big boards of ECL) is significantly less than 2.
>
>Hmmm, this is interesting.  I claim CPI has very little to do with the
>RISCiness or CISCiness of a *architecture*, to which the classifications
>refer.  The reasons are:  (1) CPI is heavily determined by implementation,
>but implementations are not CISC or RISC (perhaps they ought to be, or we
>should have classifications for implementations) and (2) CPI is heavily
>determined by what instructions are executed, e.g., I can write a program
>that uses only the fast instructions of the upcoming re-implementations
>of popular CISCs to get the CPI down (this is, in fact, what the updated
>compilers for these micros will do), but does this make these architectures
>RISCs?  Perhaps some would argue yes, but realistically, the architecture
>hasn't changed, i.e., the old, slow instruction are still there, and they
>are still slow (and old :-).  Comments?

   I agree with you.  I only used the CPI as a rough shorthand because I
didn't want to go into details.  At present, I do think there's a
rough correlation between architectures for which there
are (or could be) implementations with moderate amounts of hardware running 
at low CPIs on typical code and the common vague notions of "risciness".  
Conversely, the most commonly cited disadvantages of complex instruction sets 
are those things that make them difficult to execute in a small number of
cycles, suitable for pipelining: complex addressing modes, instruction formats 
that must be decoded interpretively, lots of backward dependencies in the
code (condition codes set by most instructions), and generally anything that
takes a variable number of cycles.  

   With only a couple of exceptions, the Elxsi instruction set can be divided 
into three classes:
1. Instructions which can be executed with moderate amounts of hardware in
   a single cycle on a pipelined CPU (not counting the inevitable enemies of
   cache misses, register conflicts, etc.)
2. Instructions which can be executed by a few cycles of low-level microcode
   or fancy hardware (e.g. floating point).
3. Instructions which can be punted to software for emulation through type-1
   instructions.  This is hypercode in our terminology; macrocode in Amdahl's
   Our message system and low-level scheduler fall into this category.

   Type 1 and 2 instructions are the same kinds of things found on any risc
machine; the reasons I consider us further towards the cisc end of the
continuum than SPARC or MIPS are:
1. Class 1 instructions require somewhat more hardware than a "real" risc --
   instructions are hardware-decodeable and there are no multi-step address
   modes, but there are 14 or so of them.
2. There are more class-2 instructions than some riscs (e.g. there are
   several instructions such as exit which would require lots of hardware to
   reduce to 1 cycle).
3. "Real" riscs don't define class 3-type things as instructions at all.

   On the other hand, there are almost no things that fall into class 2 which
you can (and obviously should) do with class 1 instructions.  This is in 
contrast to the forthcoming low-CPI implementations of popular CISCs.

Russell Williams
..uunet!elxsi!rw
..ucbvax!sun!elxsi!rw