Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!usc!snorkelwacker!spdcc!merk!alliant!linus!bs From: bs@linus.UUCP (Robert D. Silverman) Newsgroups: comp.arch Subject: Re: Integer Multiply/Divide on Sparc Message-ID: <84983@linus.UUCP> Date: 27 Dec 89 14:15:42 GMT References: <84768@linus.UUCP> <8840004@hpfcso.HP.COM> Reply-To: bs@linus.UUCP (Robert D. Silverman) Organization: The MITRE Corporation, Bedford MA Lines: 71 In article <8840004@hpfcso.HP.COM> dgr@hpfcso.HP.COM (Dave Roberts) writes: : I wrote: :>The SPARC is brain dead [as were its designers] when it comes to doing :>integer arithmetic. It can't multiply and it can't divide. : :Geeze Bob, : The thing is a SPARC. It's a RISC machine. Integer mult and :divide are the first things to go when you design a RISC. There should Huh? A computer that can't perform basic arithmetic? [add, subtract, multiply, divide]. What have you been smoking? Integer mult/divide should NOT be the first things to go. [look at the MIPS chip, a far superior design in my opinion]. Integer mult/divide may not be much used for most applications, but when they are required, not having hardware support is an absolute KILLER of algorithms. I have code that runs **slower** on the newest SPARCstation [SUN-4/330] than it does on a SUN-3/60, ONLY BECAUSE it can't multiply and divide. This is despite the fact that the SPARC is purported to be at least 10x faster. The RISC designers who put together SPARC may have been looking at the 'broad picture', but they sure as hell didn't know a lot about computer arithmetic or algorithms. :be some funky instructions to help you out, like "shift and add" for :multiplication. Trust me, you're better off (in speed, that is) for :not having those functions, and I'll be that you can write a routine I AM NOT BETTER OFF, and don't speak for me. The fact that you say 'trust me ....', indicates that you don't know diddly when it comes to the implementation and design of numerical and semi-numerical algorithms. Shift and add to perform general multiplication is hopelessly slow because of the overhead/bookkeeping/control mechanisms involved. :that can do them just about as fast as they could internally. Huh? The MIPS-R3000 does integer multiplies in hardware in just a couple of cycles. The SPARC takes a minimum of 47 cycles using its so-called multiply-step function to multiply two integers. Division is even worse by almost an order of magnitude. It never ceases to amaze me how RISC zealots immediately jump up anytime anyone should [GOD forbid!] criticize a RISC instruction set. Especially when those zealots know very little about numerical algorithms. :I don't really know much about SPARCs but I know that the designers Yet, you are willing to say 'trust me I know better' in a knee-jerk response to my posting. :at Sun weren't "brain dead". I didn't say they were. I say that they were with respect to their knowledge of how arithmetic should be done. The fact that they perceived integer mult/divide as unimportant is indicative that they were unaware how important they are for applications that require them. On the other hand, the SPARC may have been designed ONLY for the majority of programs that don't need mult/divide. If so, its design was driven by MARKETING decisions, not technical ones. Criticism of the chip on a theoretical basis is more than justified. -- Bob Silverman #include Internet: bs@linus.mitre.org; UUCP: {decvax,philabs}!linus!bs Mitre Corporation, Bedford, MA 01730