Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!yale!mfci!rodman
From: rodman@mfci.UUCP (Paul Rodman)
Newsgroups: comp.arch
Subject: Re: RISC as a "technology window"?
Message-ID: <758@m3.mfci.UUCP>
Date: 7 Apr 89 12:45:20 GMT
References: <1552@vicom.COM> <15690@cup.portal.com> <1562@vicom.COM> <726@m3.mfci.UUCP> <3070@uvacs.cs.Virginia.EDU>
Sender: rodman@mfci.UUCP
Reply-To: rodman@mfci.UUCP (Paul Rodman)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 51

In article <3070@uvacs.cs.Virginia.EDU> mac@uvacs.cs.Virginia.EDU (Alex Colvin) writes:
>> In most f.p. codes the integer unit generates 
>> addresses and program counter values, neither of which are needed
>> by the f.p. unit.  What the f.p. unit needs, on the other hand, is
>> a decent bandwidth to cache and/or memory. 
>
>Ah, but the FP has to have addresses to use on its bandwidth to memory.  In
>particular, subscripting and such address arithmetic come from the integer
>unit.
>

Oh really? What would I want to do with those addresses in the f.p. unit?
Convert them to floating point? The addresses go to memory, on behalf
of the f.p. unit, they don't go *to* the f.p. unit (!?%$*) No connection
between the two is required for this purpose!


>Wasn't there a simulation done many years ago of one of the high-end 360s
>(the one with the multiple FP stations) which showed that the bottleneck
>was the integer unit's generation of addresses?
>

Probably. And once you have that, you had better have a memory system that
will accept said addresses.

I know that on the Trace 7 we have the ability to do 4 integer ops for
every 2 flops. 2 of the integer ops can be load/stores with a base+scaled
offset type of add. The other two integer ops get used for loop exit 
tests (you do a lot for an unrolled loop), whacking induction varables,
random index arithmetic, random integer arith. , and anything else you 
need to do without burping the memory loads/store address being generated
on the other ialu.
It was obvious that this ialu bandwidth was required from very early 
simulation results.

>Of course, the 360 required more address arithmetic than many newer
>machines, and FORTRAN programs have to do all their address arithmetic as
>subscripting, in contrast to newer languages.  I wonder if anyone has done
>a study recently.

I'm curious why you think that Fortran would require more complicated
addressing modes than newer languages?

Bye,



    Paul K. Rodman 
    rodman@mfci.uucp
    __... ...__    _.. .   _._ ._ .____ __.. ._