Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!winchester!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: Integer Multiply/Divide on Sparc Message-ID: <33984@mips.mips.COM> Date: 28 Dec 89 16:15:55 GMT References: <84768@linus.UUCP> <8840004@hpfcso.HP.COM> <1804@l.cc.purdue.edu> <1535@cbnewsi.ATT.COM> <6908@cbnewsh.ATT.COM> Sender: news@mips.COM Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Inc. Lines: 30 In article <6908@cbnewsh.ATT.COM> beyer@cbnewsh.ATT.COM (jean-david.beyer) writes: >pointer dereferencing (those pointing to structures). In these cases, >the multiply instructions are mostly multiplications by constants. These >constants frequently have a small number of 1's. Consequently, instead of >calling a general purpose multiply subroutine, it suffices to insert a >special purpose inline code that multiplies by the desired constant. >(it might even pay to do a strength reduction optimization). This can be >much faster than the general purpose multiply subroutine, and may be faster >than a hardware multiply instruction, depending on the design of the >hardware multiply. Many compilers do this. For sure, HP PA, MIPS, and SPARC, but I suspect most of the other current RISCs as well, and I imagine many CISCs. It's helpful to have the assembler offer a multiply pseudo-op that turns into the best sequence of shifts/adds/subs (or whatever, such as the combined ops that HP PA has), up to the point where just issuing a multiply is better [i.e., on MIPS or 88K, which have H/W multiplies.] At least in our case, multiply/divide was put in even knowing how much of the structure-reference multiplies was going to go away, because there were enough benchmarks where muls & divs wouldn't go away; as usual, it depends on the benchmark set you use as to which way you jump on this, and which implementation technologies you've got, etc, and thoughtful people have picked both ways, recently, meaning it's at least a yet-to-be-resolved argument :-) -- -john mashey DISCLAIMER: UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086