Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!think!snorkelwacker!spdcc!esegue!johnl From: johnl@esegue.segue.boston.ma.us (John R. Levine) Newsgroups: comp.arch Subject: Re: Integer multiply and killer micros Message-ID: <1990Jan9.015043.5036@esegue.segue.boston.ma.us> Date: 9 Jan 90 01:50:43 GMT References: <158@csinc.UUCP> <787@stat.fsu.edu> <42701@lll-winken.LLNL.GOV> <5842@ncar.ucar.edu> <490@qusunl.queensu.CA> Reply-To: johnl@esegue.segue.boston.ma.us (John R. Levine) Organization: Segue Software, Cambridge MA Lines: 19 In article Daniel.Stodolsky@cs.cmu.edu writes: >... one should be able to compute a 32 x 32 -> 64 bit multiply with four >16x16 -> 32 multiplies, 4 32 bit adds and a few shifts. So why not put some >big memory killer micros to work and have a 16 by 16 multiply lookup table? >It would consume 10 megs of core, but that's nothing for a KILLER MICRO. 10 meg? A 16x16 lookup table is 2^32 entries of 32 bits each, which by my arithmetic is 16 gigabytes of memory, a little rich for even a mainframe these days. And imagine testing the damn thing. You have to test every word and verify it against an independently computed value; if each test took 5us, a single pass through it would take six hours. Perhaps this isn't the right technology yet. I do know there are medium sized combinatorial multipliers, perhaps a little pushing on them would be more productive. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl "Now, we are all jelly doughnuts."