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) |
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.
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.