Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ukma!rutgers!njin!princeton!phoenix!mbkennel
From: mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel)
Newsgroups: comp.arch
Subject: Re: Bandwidth and RISC vs. CISC
Message-ID: <7895@phoenix.Princeton.EDU>
Date: 21 Apr 89 21:52:34 GMT
References: <38853@bbn.COM> <423@bnr-fos.UUCP> <17417@cup.portal.com> <38971@bbn.COM>
Reply-To: mbkennel@phoenix.Princeton.EDU (Matthew B. Kennel)
Distribution: na
Organization: Princeton University, NJ
Lines: 43

In article <38971@bbn.COM> slackey@BBN.COM (Stan Lackey) writes:
>In article <17417@cup.portal.com) bcase@cup.portal.com (Brian bcase Case) writes:
)))of data latency.  The basic premise of RISC is to not telll the CPU anything
)))until the last moment. This strikes me as a funny way of optimizing throughput.
))
))This strikes me as a funny way of interpreting RISC!!! :-)  There are
))several "basic premises" of RISC, and as far as I know, none of them is "to
))not tell the CPU anything until the last moment."  Conversely, as far as I
)
)Stuff like vector instructions, the VAX character string instructions,
)VAX CALL/RET, the 680x0 MOVEM, etc.  give the CPU a real strong hint
)as to what near-future memory accesses will be.  As memory access times 
)become even longer [relative to cycle time], this becomes more important.
)And will begin to widen the performance gap, if implemented properly.
)RISC architectures don't have the ability to communicate this class 
)of information, and if it is added, they won't be RISC's anymore (unless 
)Marketing SAYS they are, I guess...)

I thought that many RISC chips have this property already: load delays.
You tell it to load some register or something or other but it wont
be valid until n cycles later.  In the meantime, though, you can have it
run the exact instructions that YOU want it do to for your program, and not
what the microcode programmer thought would be a commonly used bundle.  It's
the same effect--just more general purpose.

)
)I have a real problem with anything that includes IEEE floating point
)AND calls itself a RISC.  IEEE FP violates every rule of RISC; it has
)features that compilers will never use (rounding modes), features that
)are rarely needed that slow things down (denormalized operands), and
)features that make things complex that nobody needs (round-to-even).
)I'd really like to see someone stand up and say, "Boy, the IEEE
)round-to-even is much more accurate than DEC's round .5 up.  I have an
)application right here that proves it."  Or, "Gradual underflow is
)much better.  I have an application that can be run in single precision
)that would need to be run double precision without it."
):-) Stan

What do you think would be better?  


Matt Kennel
mbkennel@phoenix.princeton.edu