Xref: utzoo comp.arch:10428 misc.wanted:5381 comp.sources.wanted:7901
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!bbn.com!slackey
From: slackey@bbn.com (Stan Lackey)
Newsgroups: comp.arch,misc.wanted,comp.sources.wanted
Subject: Re: MIPS Assembler Procedure
Message-ID: <42117@bbn.COM>
Date: 28 Jun 89 21:20:52 GMT
References: <57125@linus.UUCP> <1989Jun24.230056.27774@utzoo.uucp> <41957@bbn.COM> <57725@linus.UUCP>
Sender: news@bbn.COM
Reply-To: slackey@BBN.COM (Stan Lackey)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 26

In article <57725@linus.UUCP> bs@gauss.UUCP (Robert D. Silverman) writes:
>In article <41957@bbn.COM> slackey@BBN.COM (Stan Lackey) writes:
>:The RISC suppliers would like us (users) to believe that RISC is
>:ALWAYS faster.

>:The moral of the story: If your application needs mul and div
>:performance, get a micro with hardware support for them.  If that
>:means using a CISC, so be it.

>The problem with CISC is that no one is likely to come out with a 40MIP
>CISC in the near future [e.g. i860].

I believe that now that the transistors/chip is high enough, you WILL
see CISC's that perform equal to or greater than RISC's of the same
technology.  Wait and see.  I'll wait and see if there is really ever
an i860 that delivers a consistent 40MIPS across a broad range of
applications.

>I also include add, subtract and add/subtract with carry. How else
>would you compute AB/C or AB % C exactly?

This is my point - it's OK to have slower cycles, if each cycle does
more work.  If it takes a RISC 100 20ns cycles to do the operation you
need, and the CISC 10 50ns cycles, the CISC is faster.  Microcoded
transcendentals are an example.
-Stan