Re: Caller/Callee saved Registers

hbaker@netcom.com (Henry G. Baker)
Sat, 23 Apr 1994 19:06:20 GMT

          From comp.compilers

Related articles
[29 earlier articles]
Re: Caller/Callee saved Registers hbaker@netcom.com (1994-03-29)
Re: Caller/Callee saved Registers pardo@cs.washington.edu (1994-03-31)
Re: Caller/Callee saved Registers conway@munta.cs.mu.OZ.AU (1994-04-02)
Summary -- Caller vs. Callee Saves bart@cs.uoregon.edu (1994-04-06)
Re: Caller/Callee saved Registers nandu@cs.clemson.edu (1994-04-21)
Re: Caller/Callee saved Registers preston@noel.cs.rice.edu (1994-04-22)
Re: Caller/Callee saved Registers hbaker@netcom.com (1994-04-23)
Re: Caller/Callee saved Registers preston@noel.cs.rice.edu (1994-04-26)
| List of all articles for this month |
Newsgroups: comp.compilers
From: hbaker@netcom.com (Henry G. Baker)
Keywords: registers, optimize
Organization: nil
References: 94-04-033 94-04-153
Date: Sat, 23 Apr 1994 19:06:20 GMT

preston@noel.cs.rice.edu (Preston Briggs) writes:
+Steele and Sussman propose an alternative
-resource called "racks". Rather than a set of registers and a stack,
+their machine would have a set of these racks. A rack has 4 operations:
- Assign(R, V) -- make V the current value of the rack R
+ Fetch(R) -- return the current value of the rack R
- Save(R) -- save (probably on an internal stack) the current
+ value of the rack R
- Restore -- restore the current value of the rack R
+So, obviously we can use a bunch of these things as registers, simply
-issuing Saves and Restores around procedure calls.


I haven't considered 'racks' all that carefully, but my first question is
how non-stack environments can be properly handled -- i.e., closures.
I haven't read the paper in some time, but I don't recall a solution
to the problem of closures.


Equally interesting is what happens in the case of non-local returns --
i.e., longjmp & various kinds of signals.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.