Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!ames!sgi!shinobu!odin!maddog!pkr
From: pkr@maddog.sgi.com (Phil Ronzone)
Newsgroups: comp.arch
Subject: Re: CISC Silent Spring
Message-ID: <3567@odin.SGI.COM>
Date: 5 Feb 90 02:59:59 GMT
References: <3300098@m.cs.uiuc.edu> <771@sce.carleton.ca> <35456@mips.mips.COM> <25cb6b65.702c@polyslo.CalPoly.EDU> <7826@pt.cs.cmu.edu> <3562@odin.SGI.COM> <4537@brazos.Rice.edu>
Sender: news@odin.SGI.COM
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 54

In article <4537@brazos.Rice.edu> preston@titan.rice.edu (Preston Briggs) writes:
>So, no matter how fast the CISC people make that "add from memory"
>instruction run, it won't matter much because it isn't used much.


I was too brief. Perhaps in a sense, I am saying that RISC is a non-concept,
or a transient "necessary evil".

Clearly we have (at least) two technological thrusts for RISC:

1). Compiler technology
2). Highly automated designed tools that cross the threshold of
    the minimal number gates needed to do something useful.

I am of the belief that as our design tools progress, they will
go far beyong what is needed for RISC. At some stage, we'll get
into the ranges of handling large word width microcoded machines.

Such microcoded machines can certainly execute many simple (i.e.,
RISC type) instructions in one cycle -- I know, I've done one.

BUT - they also can implement many useful instructions that are
not in some (or all) of the current RISC machines. From multiply to
divide to handling the TLB context to entire context switches to
(of course) FP instructions.

Since what counts is the HUMAN design time most, if they are
equivalent, then why not a CRISC? RISC instruction for typical
code generation, and the messy many for the rest of the real world.

Of course, they could be an order of magnitude difference between
RISC and CRISP/CISC, however, how much the die area and hence cost
will matter is, IMHO, not a big factor.

-------------

This came up for me because I microcode an mainly RISC machine
(stack oriented, non-virtual) that had to support unaligned data
transfer. The microcode word kept getting wider and
wider, but, I had barrel shifters in front of the memory and
in front/back of the ALU and hardware assist to keep the 16
top words of the stack in microcode registers.

It was a near joy to do unaligned word transfers -- if the
next sequential instruction was a push/pop from/to memory and
the word was unaligned 4 bytes on a 2 byte boundary, I never
lost a cycle (pre-interrupts went off in the previous instruction
so I could start the shift fetch shift in memory).


------Me and my dyslexic keyboard----------------------------------------------
Phil Ronzone   Manager Secure UNIX           pkr@sgi.COM   {decwrl,sun}!sgi!pkr
Silicon Graphics, Inc.               "I never vote, it only encourages 'em ..."
-----In honor of Minas, no spell checker was run on this posting---------------