Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!wuarchive!udel!rochester!pt.cs.cmu.edu!gandalf.cs.cmu.edu!lindsay
From: lindsay@gandalf.cs.cmu.edu (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: Optimal Computer Architectures
Message-ID: <11092@pt.cs.cmu.edu>
Date: 14 Nov 90 01:38:15 GMT
References: <212412@<1990Nov8> <3300209@m.cs.uiuc.edu> <8662@scolex.sco.COM> <1990Nov13.200051.12329@zoo.toronto.edu>
Organization: Carnegie-Mellon University, CS/RI
Lines: 32

In article <1990Nov13.200051.12329@zoo.toronto.edu>
	henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <8662@scolex.sco.COM> seanf@sco.COM (Sean Fagan) writes:
>>More to the point, *any* processor with register windows is not going to do
>>too well on deeply recursive code.
>The problem is not register
>windows vs. recursion, it is *fixed-size* register windows vs. recursion.
>SPARC ends up saving and restoring a lot of registers that aren't actually
>in use, because the allocation quantum is 16 registers.

That's a reasonable argument, but not the only one.

First, compilers for non-window machines try to dribble values out to
memory, avoiding bursts that could cause processor stalls. (The
infamous VAX "calls" instruction writes a burst, and that seriously
stalled the VAX 11/780.) Obviously, writing a bunch of windows is a
burst.

Second, it wasn't clear from the original posting that the SPARC was
actually running slower than some other machine - the poster just
said it was slow. Maybe he had a big computation? Did he try the
-O switch?

Third, programs that recurse can often be written as iterations.
All machines, SPARC included, run the iterative form faster.

I'm unconvinced that register windows are a good idea, but I'm also
unconvinced that SPARC is some sort of disaster area. 


-- 
Don		D.C.Lindsay