Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!mips!sgi!karsh@trifolium.esd.sgi.com
From: karsh@trifolium.esd.sgi.com (Bruce Karsh)
Newsgroups: comp.arch
Subject: Re: Bloat costs
Message-ID: <63065@sgi.sgi.com>
Date: 28 Jun 90 19:17:11 GMT
References: <1990Jun27.011149.2406@Stardent.COM> <63034@sgi.sgi.com> <9570@celit.fps.com>
Sender: karsh@trifolium.esd.sgi.com
Reply-To: karsh@trifolium.sgi.com (Bruce Karsh)
Distribution: na
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 36

In article <9570@celit.fps.com> ps@fps.com (Patricia Shanahan) writes:

>There is certainly a major architectural difference in SPARC between
>integer add (a register-to-register command) and integer multiply (which
>has only indirect support). However, I don't think I have seen a program
>that uses integer-complex. It would certainly not be a usable data type
>for FFT.

Integer-complex FFT's are probably executed much more often than floating
point FFT's.  There are several microprocessor chips on the market, notably
the Motorola DSP56001, which are highly optimized for exactly this
calculation.  There are lots of articles on how to do this.

>There is no architectural difference in the status of floating point add
>and floating point multiply in SPARC. They are both floating point
>register-to-register commands. Of course, it is possible that some
>implementations of SPARC do floating point adds faster than floating
>point multiplies, but the difference should not normally be very big.

The change from having integer multiplies being much faster than FP
multiplies rather than having them be slower is one of the most interesting
trends that's occuring in computer architecture.

Is it really true that SPARC fp register to register ops are all constant-
time?  Are SPARC fp adds and multiplies both equal-time?  This isn't true for
the MIPS.  Does anyone out there know for sure?

>I certainly agree that there are steps that can be taken to make FFT
>fast that would not be within the state of the art for compilation
>from a simple source, unless your compiler can recognise FFT's, and is
>in the habit of reading the latest papers on how to do them.

I want THAT compiler.

			Bruce Karsh
			karsh@sgi.com