You may find this post by the LuaJIT author Mike Pall of interest:
http://lua-users.org/lists/lua-l/2007-08/msg00506.html
--- skaller <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-08-24 at 09:44 +0200, Nicolas Cannasse wrote:
> > > Felix uses the higher level compiler trick, and generates high
> > > performance machine binaries. There's no reason for coroutines
> > > to impose any particularly onerous overhead.
> >
> > I haven't been studying the pro or cons of high and low level approachs
> > so I'm not qualified to compared how the two would apply to Neko.
> > However, I tend to favor highlevel approaches when they are possible
> > since they are less tricky to implement and more crossplatform.
>
> I haven't studied Neko so I can only guess what it does :)
>
> > > A JIT for a VM would not be using the machine stack for
> > > user data anyhow: it would be using the machine stack only
> > > for transient temporary values. The JIT has to respect the
> > > data structures used by VM-emulation (otherwise JIT generated
> > > machine code won't interoperate with interpreted code).
> >
> > Well, this can be discussed.
> >
> > Currently the Neko JIT is using the VM stack, but it could also use the
> > C stack instead, and only push back values on the VM stack when calling
> > a bytecode primitive.
> >
> > This is possible because JIT is based on a per-function basis, and
> > functions can't access outside of their local stack in Neko.
>
> Where does the callers "return address" go when you call a function?
____________________________________________________________________________________
Sick sense of humor? Visit Yahoo! TV's
Comedy with an Edge to see what's on, when.
http://tv.yahoo.com/collections/222
--
Neko : One VM to run them all
(http://nekovm.org)
