Path: utzoo!attcan!uunet!lll-winken!maddog!brooks
From: brooks@maddog.llnl.gov (Eugene Brooks)
Newsgroups: comp.arch
Subject: Re: Multiprocessor RISC
Message-ID: <13624@lll-winken.llnl.gov>
Date: 2 Nov 88 23:26:07 GMT
References: <18894@uflorida.cis.ufl.EDU> <3468@pt.cs.cmu.edu>
Sender: usenet@lll-winken.llnl.gov
Reply-To: brooks@maddog.UUCP (Eugene Brooks)
Organization: Lawrence Livermore National Laboratory
Lines: 26

In article <3468@pt.cs.cmu.edu> koopman@a.gp.cs.cmu.edu (Philip Koopman) writes:
>> 	Is there any differences between RISC and CISC to
>> 	support a multiprocessor system?
>Memory Bandwidth problems!  If you are using a shared memory model,
>memory bandwidth is often the limiting factor to how many processors
>you can put into the system.  RISC processors need a lot more
>memory bandwidth at the CPU chip than CISC processors.
The only place that the memory bandwith requirements for a RISC are validly
higher than a CISC is in the instruction stream.  The usual cache hit rates
for the instruction stream are unreal if you have any loops at all, and
the cache size required for these spiffo hit rates is well below the typcial
sizes of todays caches.  The 16K byte cache chip used on the MOT88K, considered
as an INSTRUCTION cache, is just fine.  It is a good idea to seperate code and
data caches so that cache thrashing caused by data accesses will not adversely
impact caching for the instruction stream.

RISC poses no problems at all for shared memory multiprocessors.  The potential
pipeling offered by load/store operations for memory accesses and large register
files is a distince advantage.  We used a load/store RISC architecture for the
Cerberus multiprocessor simulator specifically because the memory subsystem
could overlap a large number of requests if the load/store instruction stream
was suitably ordered.  We intitially started with the very CISC VAX instruction
set for this simulator, actually completed a full cpu simulator for it, and
then dropped it when we realized that the memory-memory-memory opcodes, where
each memory opcode could itself be an indirection of a pointer in memory,
were serious trouble for pipelining the memory accesses of multiple instructions
through a packet switch based shared memory server.