Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!uw-beaver!cornell!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!TR4.GP.CS.CMU.EDU!spot From: spot@TR4.GP.CS.CMU.EDU (Scott Draves) Newsgroups: comp.arch Subject: Re: Compilers taking advantage of architectural enhancements Message-ID: <1990Oct12.042251.18884@cs.cmu.edu> Date: 12 Oct 90 04:22:51 GMT References: <1990Oct9> <3300194@m.cs.uiuc.edu> Sender: netnews@cs.cmu.edu (USENET News Group Software) Reply-To: spot@TR4.GP.CS.CMU.EDU (Scott Draves) Organization: Carnegie Mellon University Lines: 28 |> |> |> >>Register file - large (around 128 registers, or more) |> >> Most compilers do not get enough benefit from these to justify |> >> the extra hardware, or the slowed down register access. |> > |> >In the proceedings of Sigplan 90, there's a paper about how to chew |> >lots of registers. |> > |> > Improving Register Allocation for Subscripted Variables |> > Callahan, Carr, Kennedy |> > |> >I suggested the subtitle "How to use of all those FP registers" |> >but nobody was impressed. Also, there's a limit to how many registers |> >you need, at least for scientific fortran. It depends on the speed |> >of memory and cache, speed of the FPU, and the actual applications. |> >The idea is that once the FPU is running at full speed, |> >more registers are wasted. |> shouldn't loop unrolling burn lots of registers also? when unrolling, which ceiling will you hit first, the number of registers, or the size of the I-cache? Consume Scott Draves Be Silent spot@cs.cmu.edu Die