Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!uflorida!ukma!rutgers!apple!baum
From: baum@Apple.COM (Allen J. Baum)
Newsgroups: comp.arch
Subject: Re: RISC v. CISC --more misconceptions
Message-ID: <19811@apple.Apple.COM>
Date: 1 Nov 88 19:55:56 GMT
References: <156@gloom.UUCP> <18931@apple.Apple.COM> <40@sopwith.UUCP> <19762@apple.Apple.COM> <1002@l.cc.purdue.edu>
Reply-To: baum@apple.UUCP (Allen Baum)
Organization: Apple Computer, Inc.
Lines: 65

[]
>In article <1002@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
(in response to me about integer multiplies)
>They are rare because a good programmer knows that they are slow and
>difficult to program.  If an operation takes 10 lines of code, each of
>which is expanded into one or more hardware instructions, why use it
>unless you cannot find a way around it?  The way around it may be clumsy,
>but it is very likely to beat the unavailable operation.

I'm going further than that. I'm saying they are rare because the are
unnecessary. They are rare because in the USUAL case they can be strength
reduced to additions by an optimizing compiler. This is faster than using
the obvious multiply instruction.

Integer numeric intensive applications are relatively RARE. You
(Herman Rubin personally) may do them all the time, in which case you
don't think they are rare, but as a precentage of programs run by all
computers, they are.

>If the double-precision product of two single-precision integers is required,
>and only single-precision products are available, it is necessary to go to
>single-precision products of half-precision numbers.  This takes about 20
>instructions.  How does the poster expect to do it in an average of 11 cycles?
>Many of these jobs are not being done, or are being kludged by finding ways to
>accomplish more-or-less the same results in 10 instructions.  And if a
>subroutine call is made, double the time.

First of all, the "if double-precision is required" is a BIG if. It isn't,
usually (i.e. rare-- see above definition of rare).
Secondly, many multipliers do not support single x single -> double.
Thirdly, most languages don't support it either.
And fourthly (sp?)- the fact that the operation yields a double precision
result doesn't mean that all bits are significant. When they aren't (see
rare, above), software can shortcut the operation, making it end faster,
ON THE AVERAGE.
Fifthly- the requirement for double precision INTEGER precision is rare
(see rare, above...)

>Many mathematical computations should be made in fixed-point arithmetic.  If
>one does not have the hardware available, the cost is much greater than
>floating point.  If the hardware is available, it is much cheaper.  None
>of the major languages support fixed point.  So none of the hardware gurus
>put it in, so none of the machines have it, so no one programs in it, so
>the inclusion of it is objected to as a waste of resources, etc.
>
>Another hardware operation missing on most machines is square root.  So one
>does not use algorithms requiring square roots.  Again, the circular
>argument.
>
>An application using accurate arithmetic heavily will be spending most of its
>time in multiple-precision subroutines, even with good hardware.  A time
>penalty of a factor of 10 here is obviously costly.

I agree that language and hardware don't support multiple precision fixed
point arithmetic. The circular argument is valid, but I maintain that it starts
because, as a percentage of all programs any particular family of processors
will run, these kinds of problems are exceedingly rare. 

Square root is the same category as divide. Hardware is slow, so algorithms
tend to avoid them. The reason is fundamental. The hardware is slow, and it
is exceedingly difficult to make it faster. Strangly enough, floating point
divide can be made to run much faster, because of its normalized operands.

--
		  baum@apple.com		(408)974-3385
{decwrl,hplabs}!amdahl!apple!baum