Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.arch
Subject: Re: A simple question on RISC
Message-ID: <680@quintus.UUCP>
Date: 15 Nov 88 08:40:52 GMT
References: <6544@xanth.cs.odu.edu> <75577@sun.uucp> <1618@imagine.PAWL.RPI.EDU> <419@augean.OZ>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 23

In article <419@augean.OZ> idall@augean.OZ (Ian Dall) writes:
>Can anyone tell me *why* some of these microcoded instructions were
>slower than a combination of simpler instructions on the same machine?

There have been several micro-coded machines which had hardware
support for decoding _part_ of an instruction.
For a specific case, imagine a machine which has both
	add.2	Dst,Src		Dst +:= Src
and	add.3	Dst,Src1,Src2	Dst := Src1+Src2
but suppose that the hardware has special support for decoding the
first two operands, while additional operands have to be decoded by
microcode.  Then
	mov.2	Dst,Src1
	add.2	Dst,Src2
would be fully decoded by hardware, while
	add.3	Dst,Src1,Src2
would have one of its operands decoded by microcode.

Another case would be an operation which could be done with a fast
algorithm and a large table or with a slow algorithm and no table.
For example, to find the first bit in a 16-bit word, just index
a precomputed table of 2**16 bytes (there are 17 cases).  Or do it
with a dumb ALU and no table.