Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hpda!hpcuhb!hpindda!kmont
From: kmont@hpindda.HP.COM (Kevin Montgomery)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Why The Move To RISC Architectures?  ('386 vs. RISC)
Message-ID: <40970055@hpindda.HP.COM>
Date: 27 Mar 90 00:21:24 GMT
References: <28011@cup.portal.com>
Organization: Bill and Dave's
Lines: 28

> Having said all this, my question: What type of processor lends
> itself better to highly parallel architectures, RISC or CISC?

This is what I was trying to get at earlier in the discussion (or
later, depending on the bit-wind near your site).  I agree with the 
connection approach in that 1) parallelism is necessary to dramatically 
increase performance and 2) the memory bottleneck still exists (unless
someone makes a good, fast, CHEAP dual-ported memory).  

I think the problem will be more evident with parallelized RISC machines 
than CISC machines, although the probability of CISC compiler-writers 
actually using this architectural advantage is probably low.  More likely
what will happen are RISC machines plowing ahead into parallelism and
people using huge amounts of cache to get around this problem.  Then
either an advance I can't see will happen in memory technology (which 
would be great!), or we're going to have to do more per main-memory
instruction to decrease this problem.  The return of main-memory macrocode 
and internal caching/microcode?  Maybe.  Would be a bizarre twist.  Maybe
someone will step back from our RISC code and say "Gee, these same patterns
keep showing up- why don't we eliminate it and use a macrocode opcode for
these?"  Dunno.  Then I suppose we'd end up applying what we've been pushed
to do to support RISC implementations (GaAs, CMOS, etc) to RISC+ (slightly
CISC-er RISC) implementations.

Oh well, this probably belongs in comp.arch at this point...


						kevbop