NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/amiga/programm/17752

Internet Message Format | 1992-12-23 | 3.8 KB

Xref: sparky comp.sys.amiga.programmer:17752 comp.sys.amiga.hardware:22007
Path: sparky!uunet!uunet.ca!geac!zooid!tndb!jimomura
From: [e-mail] (Jim Omura)
Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
Subject: Re:  CISC and RISC
Distribution: world
Message-ID: <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: 23 Dec 92 10:38:12 EST
Organization: Not an Organization
Lines: 73

In article <[e-mail]> [e-mail] (Michael David WINIKOFF) writes:
>[e-mail] (Jim Omura) writes:
>
>[Lots of quotes deleted]
>
>>     Putting this into context, with the current trend to multiple
>>processing to handle graphics and sound (DSPs are coming), you can
>>isolate the various processors to an extent, but there are going to
>>be times where the various busses are going to be the main bottlenecks.
>
>They already are. Bus bandwidth limitations is why you don't see any 20
>processor shared memory machines.

     Well, yes, I know that.  That's why I raised the issue in *this*
discussion where nobody else has.

>In shared memory machines one relies heavily on caches to reduce the demand
>on the bus.
>
>Another solution to having multiple processors is to build distributes
>memory machines.

     Let me repeat "there are going to be times where the various
busses are going to be the main bottleneck".  This will be true
in spite of distributed memory and caching.  Actually, I thought
I implied that fairly well.
:-)

>>Fancy DMA schemes will have to be used to optimize the resolution
>>of the contentions.  But the less a processor needs to access the
>>buss the better.  Well now, doesn't it sound like a good idea if
>>I can have 1 instruction that requires 2 buss cycles, leaving the
>>buss free for the graphics or sound processors, while the CPU does
>>the work of maybe 3 or 4 instructions?  Superscalar is going to mean
>>even more buss contention problems for such situations.  So at bottom,
>>there are going to be a lot of good reasons to have CISC processors
>>in some systems.  In fact, I expect we have seen the last of the
>>"everbody will either have either type X or type Y CPUs" and there
>>are going to be a fairly wide range of processors commonly used.
>
>Essentially what (I think) you're saying is "we shouldn't use the fastest
>CPUs we can on a multiprocessor machines since they'll be tying up more
>bus bandwidth then slower processors"

     That's close.  To state it more accurately, we're reaching a
point where certain classes of applications which push designs
in various directions have significant representation in the market.
Considering all the design specification factors (user needs and
preferences, design costs, material costs and production costs),
better performance may be achieved where overall system architectures
are optimized towards certain applications.  And some CPUs will
be better suited that others in this overall context.  More
specifically, in some designs, super-scalar RISCs simply may not
give performance as good as CISC.  Furthermore, there should be
advantages in designing CPUs with more of an eye on final applications
and working backwards through the overall system architecture
than there has been in the past.  This may be happening in the
Apple/IBM/Motorola project -- I don't know.

     I might also add that I doubt that we're close to seeing the
ultimate designs in any of these classes.

     Incidentally, the latest word I have is that the physical signals
in the Apple/IBM/Motorola RISC are essentially 88000 signals, so
that might be a good reason to design the next generation Amigas
on 88000's.

...

--

Jim Omura, [phone]
'jimomura@lsuc'