Path: utzoo!attcan!uunet!husc6!bbn!bbn.com!slackey
From: slackey@bbn.com (Stan Lackey)
Newsgroups: comp.arch
Subject: Re: A simple question on RISC
Message-ID: <32376@bbn.COM>
Date: 16 Nov 88 15:14:30 GMT
References: <6544@xanth.cs.odu.edu> <75577@sun.uucp> <1618@imagine.PAWL.RPI.EDU> <419@augean.OZ>
Sender: news@bbn.COM
Reply-To: slackey@BBN.COM (Stan Lackey)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 26

In article <419@augean.OZ> idall@augean.OZ (Ian Dall) writes:
>In article <75577@sun.uucp> khb@sun.UUCP (Keith Bierman - Sun Tactical Engineering) writes:
>> Or if they (wizzbang instructions) got used, it was
>> so rare that it didn't matter. Or they got used, and it was slower
>> than some combination of simple instructions. Or all of the above.
>Can anyone tell me *why* some of these microcoded instructions were
>slower than a combination of simpler instructions on the same machine?
A significant number of these claims come from experience on some of the VAX
machines.  There are two major cases that come to mind.

1. It was sometimes the case that the complex instruction did more
than the application required.  For example, the CALL instructions
saved a lot of stuff to the stack, aligned the stack pointer, etc.  A
compiler which implemented a "lightweight call" would run faster.

2. There was a particular detail with the VAX-11/780 INDEX instruction
- it ran slower than its emulation.  The reason is that it was
microcoded using the microcoded integer multiply.  The emulation used
the simpler MULL instruction, which was done by the floating point
accellerator.  The instruction was added to the instruction set very
late in the development, too late to make the hardware change to the
FPA.

So, aside from implementation details, I see no "RISC superiority"
arguments here.
-Stan