Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!cam-cl!news
From: cet1@cl.cam.ac.uk (C.E. Thompson)
Newsgroups: comp.arch
Subject: SPARC multiply-step instruction (was: RISC vs CISC simple load benchmark...)
Message-ID: <1990Jun13.150100.28445@cl.cam.ac.uk>
Date: 13 Jun 90 15:01:00 GMT
References: <39319@mips.mips.COM>
Reply-To: cet1@cl.cam.ac.uk (C.E. Thompson)
Organization: U of Cambridge Comp Lab, UK
Lines: 29

In article <39319@mips.mips.COM> mash@mips.COM (John Mashey) writes:
>
>Specifically, most RISC designers, after studying many programs, decided
>that integer multiply (and especially divide) were used less frequently
>than many other operations, and there is substantial data that backs this
>up from many vendors.  RISC designers, depending on the benchmarks used,
>and amount of silicon available, allocated various amounts of silicon to
>support these operations, from zero up. The SPARC designers included
>a Multiply-Step, and no Divide-Step (i.e., divides are done by fair-sized
>hunk of code); HP PA included M-S and D-S; MIPS & 88K included both
>integer mult & divide in hardware, etc.  However, for example, a typical
>integer divide on a MIPS takes about 35 cycles.... and probably about
>the same on a typical CISC.
>
I have never been able to understand why the SPARC multiply-step instruction
was included at all. It only delivers a puny one bit per cycle, which makes
it quite hard find to cases where it is the right way of doing a multiply
(or at any rate, cases when it is *faster* than alternative code). 
Compilers generating code for multiplication by small constants will do  
better using addition/shift chains; and when you need a general 32x32 bit
multiply you can do better with difference-of-squares and lookup tables
than with a chain of 32 multiply-step instructions. I suppose that the
multiply-step is conceptually simpler than these techniques, but the
absence of a divide-step instruction makes it difficult to believe that
this is the rationale.

Chris Thompson
JANET:    cet1@uk.ac.cam.phx
Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk