Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucsd!network.ucsd.edu!celit!ps
From: ps@fps.com (Patricia Shanahan)
Newsgroups: comp.arch
Subject: Re: Bloat costs
Message-ID: <9570@celit.fps.com>
Date: 28 Jun 90 15:23:37 GMT
References: <1990Jun27.011149.2406@Stardent.COM> <63034@sgi.sgi.com>
Sender: daemon@fps.com
Reply-To: ps@fps.com (Patricia Shanahan)
Distribution: na
Organization: FPS Computing Inc., San Diego CA
Lines: 35

In article <63034@sgi.sgi.com> karsh@trifolium.sgi.com (Bruce Karsh) writes:
>In article <1990Jun27.011149.2406@Stardent.COM> wright@stardent.Stardent.COM (David Wright @stardent) writes:
...
>
>Some architectures (e.g. SPARC) take much longer to multiply than to add.
>
...

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.

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.

...
>But the original posting stated that it was enough to just
>right clear code because the optimizer will make the most of it.  In general,
>it wont.  Maybe someday.
...

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.
--
	Patricia Shanahan
	ps@fps.com
        uucp : ucsd!celerity!ps
	phone: (619) 271-9940