Xref: utzoo comp.arch:10382 misc.wanted:5347 comp.sources.wanted:7846
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!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: <41957@bbn.COM>
Date: 26 Jun 89 15:05:54 GMT
References: <57125@linus.UUCP> <1989Jun24.230056.27774@utzoo.uucp>
Sender: news@bbn.COM
Reply-To: slackey@BBN.COM (Stan Lackey)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 25

In article <1989Jun24.230056.27774@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes:
>In article <57125@linus.UUCP> bs@gauss.UUCP (Robert D. Silverman) writes:
>>This, in my opinion is one of the major faults of RISC processors. They
>>do not provide basic arithmetic instructions. 
>
>When the list of "basic" arithmetic instructions is pages long, one starts
>to wonder how many of them are really "basic".  The instruction you ask
>for -- divide double length by single length yielding single-length result --
>is not exactly frequently needed.  Just how much silicon is it worth to make
>it run faster than an implementation as a subroutine?

The RISC suppliers would like us (users) to believe that RISC is
ALWAYS faster.  I can't help thinking back to when Patterson's first
RISC papers came out.  He managed to tune the code on his RISC until
all of the benchmarks ran faster than the VAX 11/780, except for one,
which happened to exercise one of the microcoded character string
instructions a lot.

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.

BTW:  divide-double-by-single-yielding-single is the one the 68000
included.  Is there a chicken-and-egg situation here?
-Stan