Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!ukma!rutgers!cmcl2!yale!mfci!rodman From: rodman@mfci.UUCP (Paul Rodman) Newsgroups: comp.arch Subject: Re: When is RISC not RISC? Message-ID: <644@m3.mfci.UUCP> Date: 14 Feb 89 16:31:40 GMT References: <4592@tekgvs.LABS.TEK.COM> <8476@aw.sei.cmu.edu> <5964@cbmvax.UUCP> Sender: rodman@mfci.UUCP Reply-To: rodman@mfci.UUCP (Paul Rodman) Organization: Multiflow Computer Inc., Branford Ct. 06405 Lines: 43 In article <5964@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: > > Very slightly, since PFX is an instruction, it just routes the result >to the immediate value register. The most complex part of this (not very) >is shifting the value in the IVR over when a PFX is executed (easy because >it's a fixed shift). > You mean it takes me *cycles* to build a >4 bit constant??? *Gasp,choke.* I guess thats fine for some machines, but if you're reading 4 x 64 bit words from a large array every beat from a common block, you may need lots of constants without such a penalty. I'd much rather have the instruction bits to do *exactly* what I (i.e. the compiler) want to do, than have a program that is statically smaller. Cache, main memory, and disk are cheap and getting cheaper. Anytime I can trade them for speed its a win. > > I say there is no difference in Icache complexity due to 16-bit >instructions. There would be on a machine that was trying to do more than one lousy operation per cycle. Therefor, you should get twice as many instructions into >it, and if the 15% figure is true, then you should get effectively 15% >more done with what's in the icache. (This assumes a loop the size of the >icache. For other conditions, it may change the hit-rate instead.) Icaches can be made huge. Who cares? > > Icache is what makes the world go around. The next stepping stone: >making dcaches more efficient (their current hit-rates are lousy unless they're >ridiculously large). Why not have a *real* pipelined memory system and a compiler than can handle more than one miserable outstanding load in flight? Or have both. Paul Rodman rodman@mfci.uucp