Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!snorkelwacker.mit.edu!husc6!encore!jcallen
From: jcallen@Encore.COM (Jerry Callen)
Newsgroups: comp.arch
Subject: Re: Optimal Computer Architectures
Summary: What's wrong with a burst save/restore?
Message-ID: <13256@encore.Encore.COM>
Date: 14 Nov 90 15:35:01 GMT
References: <212412@<1990Nov8> <3300209@m.cs.uiuc.edu> <8662@scolex.sco.COM> <1990Nov13.200051.12329@zoo.toronto.edu> <11092@pt.cs.cmu.edu>
Reply-To: jcallen@encore.Com (Jerry Callen)
Organization: Encore Computer Corp, Marlboro, MA
Lines: 25

In article <11092@pt.cs.cmu.edu> lindsay@gandalf.cs.cmu.edu (Donald Lindsay) writes:
>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.

I'm curious what's wrong with a burst write of registers out to memory?
It seem to me that an intelligent memory system (maybe with a hint
from the processor that a burst is coming) could accept one word per
cycle and get those registers out to memory very fast. If the processor
is "stalled" while the registers go out, how is this different from
procedure prologue code in a RISC that does a bunch of stores in a row?
In fact, the RISC has to fetch the instructions, so the RISC should take
MORE time to save the registers.

I'l take a stab at answering my own question (I like talking to myself :-)).
Conceivably the RISC could NOT do the saves as a block in the prologue, but
(as Donald says) dribble them out as the register is needed. One complication 
here is that the epilogue has to have some way of knowing which registers
actually have to be restored (in the case of multiple returns, or, for
Ada, exceptions).

-- Jerry Callen
   jcallen@encore.com