Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!portal!cup.portal.com!bcase
From: bcase@cup.portal.com (Brian bcase Case)
Newsgroups: comp.arch
Subject: Re: Intel/MIPS Dhrystone ratio
Message-ID: <15901@cup.portal.com>
Date: 16 Mar 89 19:20:32 GMT
References: <1552@vicom.COM> <15690@cup.portal.com> <1562@vicom.COM> <37196@bbn.COM>
Organization: The Portal System (TM)
Lines: 25


 >RISC is indeed a technology window, driven largely by the amount of
 >stuff you can fit in a chip.  Look at what is being added now that you
 >can fit more than a simple CPU core in a chip:
 >
 >   Floating Point
RISCs can have floating point; floating-point is not CISCy.
 >   29000 null-terminated-string handling instructions
There's only one, and it is *QUITE* simple.  Even if it shouldn't be
there, this is does not support what Nick says.
 >   Choice of endian-ness
This adds about 2 gates to the design.
 >   Caches; in fact with extremely complex, multi-mode capabilities
???  This might have some effect on the instruction set, but the effect
should not be to make the basic instructions go slow.
 >   Fully associative address translation caches
This is architecturally neutral.
 >   Harvard architecture
This is simply required for performance, regardless of the instruction set.
 >   Multiprocessor capability
I don't see how adding multiprocessor capabilities makes a RISC into a
CISC.

None of this stuff is inconsistent with RISC.  These are not CISCy
things.  If you are going to complain, make your complaints valid.