|Implementation of true closures firstname.lastname@example.org (Rohit Lodha) (2005-02-03)|
|Re: Implementation of true closures email@example.com (2005-02-06)|
|Re: Implementation of true closures firstname.lastname@example.org (Eliot Miranda) (2005-02-06)|
|Re: Implementation of true closures email@example.com (Basile Starynkevitch \[news\]) (2005-02-06)|
|From:||firstname.lastname@example.org (Anton Ertl)|
|Date:||6 Feb 2005 15:00:37 -0500|
|Organization:||Institut fuer Computersprachen, Technische Universitaet Wien|
|Posted-Date:||06 Feb 2005 15:00:36 EST|
"Rohit Lodha" <email@example.com> writes:
>Ruby has true closures and I am trying to implement a Virtual Machine
Just in case you are not already aware of it, there is the Carbone
project for a VM for Ruby: <http://www.nongnu.org/carbone/README.html>
It seems to be dormant now, and I don't know if closures were
implemented there, but in any case you might want to contact Markus
Liedl about his ideas.
> I have 2 options for effective implementation.
>1) Using frame on the heap instead of the stack.
That's probably what I would do. Later you can optimize some of the
heap frames to stack frames, and further split heap frames into the
long-lived variables that have to be kept on the heap, and the part
that can live with a stack regime (e.g., the return address unless you
also have first-class continuations).
If you expect VM programs to have a persistent life, you might want to
design your VM for these optimizations even if your compiler does not
use them at first.
>2) Using setjmp/longjmp and saving state across procedure calls.
I am not really sure what you mean here, but the following things come
to my mind:
- There are a number of ways that people think of for implementing
closures that seem to work for not-too-complex cases, but do the wrong
thing in various corneer cases (see the recent discussion in comp.arch
on closures <2005Jan8.firstname.lastname@example.org> for an
- I would not use a C-level call for implementing the VM-level call
even if the VM call and return semantics allowed a stack regime, for
efficiency reasons; the C function containing the code for the VM
instructions is pretty big, and typically has quite a number of locals
that it wants to set up on entry. I have never done any measurements
comparing the approaches, though.#
M. Anton Ertl
Return to the
Search the comp.compilers archives again.