Hello,

I have started to implementing an AngelScript JIT using LLVM, mostly for fun and learning: https://github.com/AsuMagic/angelscript-llvm
Right now it is very very primitive, but I have managed to successfully JIT an integer add function from its bytecode alone, and successfully return to the VM.

I have currently implemented it in such a way that every AS function that gets JIT'd generates two functions:

• An internal function with a signature that is roughly the same as that of the AS function.
• A “jit entry” function that is an asJITFunction, which calls the internal function by reading out the parameters from the AS stack and writing the return value to the valueRegister.

I have a few questions:

1. Currently, I am making the assumption that a function will be either completely JIT'd, either not at all.
   This implies that I expect a jit entry point to be at the beginning of every function, and I return control to the VM at the asBC_RET bytecode instruction.
   Assuming this turns into a complete bytecode implementation, every single function should be able to be JIT'd.
   Is this a safe assumption to make?
2. Are there any things to consider for script to script function calls if bypassing the AS VM for these? I can imagine significant benefits to do this since LLVM would be able to inline those calls pretty trivially most likely.
3. Likewise, is it important that I restore the VM registers (stack, stack frame and bytecode pointer) when performing a system call (both with the generic and C calling convention) if bypassing the AS VM for these calls?
4. How exactly is the stackPointer used in the bytecode? Are the Psh* opcodes strictly only used in order to prepare function calls?

Thanks!

Ok, I figured out from reading some testing and function disassembly that the answer to 4 is “no”. I was originally confused as to how the stack pointer was determined but I figured out: it's fp + the reserved temporary and local variable area.
So I'm adding one or two questions instead:

• Is it reliable to determine the location of that stack pointer by deducing from instructions writing to local variables where the highest stack temporary relative to the stack frame pointer is, and as such where the stack pointer should be?
• Are there any values on the stack that can be larger than 64-bit? Currently, the way I have implemented relies on that, but I figured that might not be reliable. For each temporary “slot” on the stack I currently emit an alloca of i64 that I then bitcast as necessary.

Tat's a very interesting project. I guess it could be easily ported to other platforms / processors if the backend is LLVM.

Please keep us posted!