Re: Implementation of true closures

"Rohit Lodha" <rohitlodha@gmail.com> writes:
>Ruby has true closures and I am trying to implement a Virtual Machine
>for it.


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.105712@mips.complang.tuwien.ac.at> for an
example).


- 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.#


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/home.html

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