Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!microsoft!w-colinp From: w-colinp@microsoft.UUCP (Colin Plumb) Newsgroups: comp.arch Subject: Re: When is RISC not RISC? Message-ID: <674@microsoft.UUCP> Date: 16 Feb 89 06:25:38 GMT References: <4592@tekgvs.LABS.TEK.COM> <8476@aw.sei.cmu.edu> <5964@cbmvax.UUCP> <644@m3.mfci.UUCP> Reply-To: w-colinp@microsoft.uucp (Colin Plumb) Organization: very little Lines: 28 rodman@mfci.UUCP (Paul Rodman) wrote: > 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. You's *hate* the transputer. It takes one prefix instruction per 4 bits. Currently, that's one cycle per 4 bits (past the first). There are some noises about speeding up this particular part of the decode process. > Icaches can be made huge. Who cares? Anyone who wants 15% more icache than the competitor. Assume we both have the same icache technology. If my instructions are denser, I get more of my inner loop in the icache, and run faster. If the denser instructions don't cost me in decode as much as they get me in hit rate, I win. Although, as you point out, icache capacity is a rapidly moving target. Still, it can be a valid tradeoff. -- -Colin (uunet!microsoft!w-colinp) "Don't listen to me. I never do."