> 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. > 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. Nicolas -- Neko : One VM to run them all (http://nekovm.org)
