Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: register save
Message-ID: <7613@mentor.cc.purdue.edu>
Date: 11 Mar 91 13:37:12 GMT
References: <3219@crdos1.crd.ge.COM> <12234@pt.cs.cmu.edu> <1991Mar07.014907.11081@kithrup.COM>
Sender: news@mentor.cc.purdue.edu
Lines: 58

In article <1991Mar07.014907.11081@kithrup.COM>, sef@kithrup.COM (Sean Eric Fagan) writes:
> In article <7403@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
> >The relevant question is, "How bad is this from the standpoint of the possible
> >alternatives?"  In a subroutine call, the following is involved:
> >
> >	Save the system state register and set up the new one.
> >	Save the modified program counter.
> >	Save those registers which should be saved.
> >	Save any other information needed to restore.
> >
> >On return, this needs to be reversed.
> >
> >So we have in the neighborhood of a half-dozen to more than a dozen things to
> >do.  In addition, we are likely to have cache failures.  I do not find it 
> >at all unusual that this instruction averages 10 times as long as other
> >instructions.
> 
> Why, Herman?  Don't you like complex instructions?
> 
> One of the reasons the vax calls instruction is so slow is, as was pointed
> out by another poster, that, in addition to what you describe, it also goes
> out and fetches 16 bits at the specified address, uses that to determine
> which registers to save, and then jumps to address+2bytes.  Ugh.  Too many
> memory references for my taste.  Note, also, that there is no reason why you
> should save the status register ("condition codes"); in fact, you may want
> to use that (if present) to determine what you should do.  (E.g.,

			............................

Unless one is going to save all registers, it is necessary to know which ones
to save.  I am used to situations (call them "planned exceptions", if you will)
in which the subroutine call is a rare occurrence.  Now there is a way around
this at some hardware cost if one would have a means of instructing the machine
to proceed in a particular manner unless a user interrupt occurs, and to be
able to reset in that case.

If a machine has a goodly number of registers, the "normal" situation will
be for a program to be using lots of them.  It is not that unusual for a
subroutine, even one doing a fair amount of work, to use many less.  For
the caller to save registers without regard for what the callee uses will
be expensive unless there is some automatic means of doing this such as
register blocks on the PYRAMID.  Otherwise there has to be some means of
finding out which registers the callee uses, and reading the mask is about
as quick a way as any.

I do not think our current instructions are complex enough, in many situations.
In a register saving situation without register blocks, the memory references
are needed.  Now one could have anticipating reads of the save mask, so that
that reference will not slow things down.  If one wants to use an intersection
mask, an "old active" mask for subsequent calls will still be needed.

You do need to save such things as the status register.  The old status
register should still be available if one wants to use it.

--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)