|[29 earlier articles]|
|Re: Caller/Callee saved Registers email@example.com (1994-03-29)|
|Re: Caller/Callee saved Registers firstname.lastname@example.org (1994-03-31)|
|Re: Caller/Callee saved Registers email@example.com.OZ.AU (1994-04-02)|
|Summary -- Caller vs. Callee Saves firstname.lastname@example.org (1994-04-06)|
|Re: Caller/Callee saved Registers email@example.com (1994-04-21)|
|Re: Caller/Callee saved Registers firstname.lastname@example.org (1994-04-22)|
|Re: Caller/Callee saved Registers email@example.com (1994-04-23)|
|Re: Caller/Callee saved Registers firstname.lastname@example.org (1994-04-26)|
|From:||email@example.com (Henry G. Baker)|
|Date:||Sat, 23 Apr 1994 19:06:20 GMT|
firstname.lastname@example.org (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
Search the comp.compilers archives again.