Article View: comp.arch
Article #20690Re: RISC as a "technology window"?
From: Paul Rodman
Date: Fri, 07 Apr 1989 12:45
Date: Fri, 07 Apr 1989 12:45
51 lines
2634 bytes
2634 bytes
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
__... ...__ _.. . _._ ._ .____ __.. ._
Technical Details
Message-ID:
<758@m3.mfci.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!yale!mfci!rodmanReferences:
<1552@vicom.COM> <15690@cup.portal.com> <1562@vicom.COM> <726@m3.mfci.UUCP> <3070@uvacs.cs.Virginia.EDU>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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