Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!seismo!sundc!pitstop!sun!amdcad!ames!ncar!tank!uxc!uxc.cso.uiuc.edu!urbsdc!aglew
From: aglew@urbsdc.Urbana.Gould.COM
Newsgroups: comp.arch
Subject: Re: RISC v. CISC (was The NeXT problem)
Message-ID: <28200218@urbsdc>
Date: 20 Oct 88 15:07:00 GMT
Article-I.D.: urbsdc.28200218
References: <156@gloom.UUCP>
Lines: 37
Nf-ID: #R:gloom.UUCP:156:urbsdc:28200218:000:1454
Nf-From: urbsdc.Urbana.Gould.COM!aglew    Oct 20 10:07:00 1988


>First, there is no good reason that all of the cache and pipeline
>enhancements cannot be put on to a CISC processor.

Space.

It's less of a reason now, which is way the phase of RISC may pass.

>Second, to perform a complex task, a RISC chip will need more
>instructions than a CISC chip.

There aren't many complex tasks. Code size inflation is usually due to
lack of memory to register ops, not sophisticated instructions.

>Third, given the same level of technology for each (ie caches, pipelines,
>etc), a microcode fetch is faster than a memory fetch.

I used to work for a company where, for straight line code, a microfetch
was the same speed as the memory fetch. Plus, access to main memory from
microcode was 2 to 4 times *more* expensive than access to memory from
an instruction (dedicated hardware for instruction memory accesses,
hiding most load/stores).

>As an aside, the 68030 can do a 32 bit multiply in about (If I remember 
>correctly -- I don't have the book in front of me) 40 cycles.  A while
>back, I tried to write a 32 bit multiply macro that would take less 
>than the 40 or so that the '030 took.  I didn't even come close (even 
>assuming lots of registers and a 32 bit word size (which the 6502 
>doesn't have)).  

There do exist RISCs with multiply instructions. In fact, real 
multiplies, with full multiplier arrays taking lots of space that
might otherwise have had to be used for microcode.

>Cory Kempf

Andy Glew