Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!sdcsvax!ucbvax!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: comp.arch
Subject: Optimizing multiplies (of non constants)
Message-ID: <2129@hoptoad.uucp>
Date: Thu, 14-May-87 22:41:56 EDT
Article-I.D.: hoptoad.2129
Posted: Thu May 14 22:41:56 1987
Date-Received: Sat, 16-May-87 13:32:17 EDT
References: <1270@aw.sei.cmu.edu> <138@neptune.AMD.COM> <3540@spool.WISC.EDU> <16627@amdcad.AMD.COM>
Organization: Nebula Consultants in San Francisco
Lines: 19

In article <16627@amdcad.AMD.COM>, tim@amdcad.AMD.COM (Tim Olson) writes:
>                                                                  Our C
> runtime library code we use for simulations has a multiply subroutine
> which is a variant of the one shown in the user's manual.  It performs a
> quick check at the beginning to see how many steps are really required,
> then performs only that many steps.  This has been shown to reduce the
> entire cost of a runtime multiply (including procedure-call overhead) to
> around 25 cycles (when used on a range of multiply-intensive code).

I remember Bill Joy doing a similar analysis of multiplies, using
"troff" as a particularly multiplicitive example.  You have to remember,
though, that troff and many other Unix programs were written for 16-bit
machines, so they never multiply anything that might overflow 16 bits.
While this is "representative" of portable Unix programs, it isn't
necessarily representative in general.
-- 
Copyright 1987 John Gilmore; you may redistribute only if your recipients may.
(This is an effort to bend Stargate to work with Usenet, not against it.)
{sun,ptsfa,lll-crg,ihnp4,ucbvax}!hoptoad!gnu	       gnu@ingres.berkeley.edu