A small scheme VM about xl

[c3d]

Hi @tripleo1. There is already a working implementation of XL, that's -O0 as implemented in interpreter.cpp. It is working in the sense that passes the whole test suite. Now, of course, I want to add more things to it, but the key issue at the moment is that it's just way too slow for my Tao3D use case.

Regarding your video, I'm sorry, but I am strongly not convinced. They don't really explain how they measure the footprint of the various implementations. For lua, for example, they claim 310K. That is probably the footprint of the Lua library on x86 (to which you'd need to add ~50K for luac). But for Lua, this is native, executable code. What makes me unconvinced is that they compare that native code footprint with 4K of obfuscated Javascript source code, which requires a whole Javascript VM to run, and that alone is more than the Lua VM. For example, on my machine, the node binary alone is 36M, way above the ~400K of a full Lua implementation.

XL is written in C++, not C, and not really optimized for size at the moment. So a working implementation is more in the 2M range. Larger than Lua, smaller than JavaScript, and not optimized at all for the moment (4 implementations in one binary).

What is more interesting is the source code size. Lua is 22733 lines of C code (on 5.3.0). XL is 42013 lines of C++ code, but that includes four different implementations. The LLVM and bytecode implementations account for 14126 lines of code, so what is left is 27887 lines of code. I tend to comment a lot, 8745 of the 42013 lines are comments, and 5591 are blank lines. Lua has 771 comment lines and 3724 blank lines. So overall, source code complexity is on the same order of magnitude, and I hope to keep it that way ;-)

Using C++ will definitely cost me a lot in terms of binary size, but I expect that to go down when XL self-compiles. And when I get to a point where one implementation looks good enough, I will definitely start optimizing. We are not there yet, by far.