Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!apple!usc!polyslo!mira.acs.calpoly.edu!mdeale
From: mdeale@mira.acs.calpoly.edu (Myron Deale)
Newsgroups: comp.arch
Subject: Re: Double Width Integer Multiplication and Division
Message-ID: <12208@polyslo.CalPoly.EDU>
Date: 30 Jun 89 20:42:35 GMT
References: <1035@aber-cs.UUCP> <1370@l.cc.purdue.edu>
Sender: news@polyslo.CalPoly.EDU
Reply-To: mdeale@mira.acs.calpoly.edu.UUCP (Myron Deale)
Organization: ACS, Cal Poly, San Luis
Lines: 50

In article <1370@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>In article <1035@aber-cs.UUCP>, pcg@aber-cs.UUCP (Piercarlo Grandi) writes:
>> In article <1989Jun26.195044.4197@cs.rochester.edu> crowl@cs.rochester.edu
>> (Lawrence Crowl) writes:
>> 
>> 	[1] You are not supposed to write assembler programs on a RISC
>> 	    machine. The compilers have sophisticated algorithms to generate
>> 	    "optimal" multiplication/division out of simpler instructions.
>
>I find this attitude arrogant.  Neither you nor anyone else knows what 
>complicated operations I want to do.  Why should you try to make it 
>difficult for me to use the power of the computer?

   A good point. I spend much of my time "on the outside of the envelope"
writing strange/ugly code because I'm always doing something that isn't
supported by the HLL's I have access to. For example, my present experiment
has to do with division techniques. My routine requires a 64-bit product
which the 68020 has but my compiler won't generate. Tweak time.

   It would be inane for me to complain to the compiler writers about not
having feature X. What happens is that next week I'll want feature Y, etc.
Let the compiler writers make a robust, production oriented tool, but I
won't be happy if there isn't a way to work around a problem, the HLL
itself, within reason.

   Now that it is possible to make 1 million transistor chips, it is
lame not to have capable arithmetic. The RISC generation knows how to
read and write, but their math could use working on. I'd pay a certain
price for better extended- and multi-precision arithmetic, although I
realize us math types aren't exactly a driving force in the marketplace.

>
>> 	[2] Fixed point and the "muldiv()" idea to me look very much in the
>> 	    RISC philosphy of minimalism. Fixed point, and multiple precision
>> 	    integer arithmetic, are in many many cases preferable to floating
...
>
>Mathematicians who know that floating point numbers are, in reality, only
>approximations to real numbers will not be so confused.  And good numerical
>analysts do not make this confusion.  In fact, mathematicians complain that
>they are only offered limited precision floating point.

   Perhaps it would be wise to concentrate on porting Mathematica (TM)
to an i860 or BIT SPARC, etc., in a few years. It's not fast, but it is
the best I've run across as far as multi-precision math ... and you could
afford to waste some MFLOPs on those machines. Not that you'd want to,
but for home-grown experimental code this may be an adequate approach.

Myron
// mdeale@cosmos.acs.calpoly.edu