Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!ames!haven!uvaarpa!virginia!uvacs!mac
From: mac@uvacs.cs.Virginia.EDU (Alex Colvin)
Newsgroups: comp.arch
Subject: Re: RISC as a "technology window"?
Summary: IEU/FPU coupling
Message-ID: <3070@uvacs.cs.Virginia.EDU>
Date: 5 Apr 89 18:16:55 GMT
References: <1552@vicom.COM> <15690@cup.portal.com> <1562@vicom.COM> <726@m3.mfci.UUCP>
Organization: University of Virginia
Lines: 17

> 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.

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?

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.