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.

I'm a bit short on time so I'll be brief.

1. Yes, you can assume every script function starts with JIT_ENTRY. You can return control to VM before RET if you wish.
2. You only need to update the VM for JITed script to script calls if there is a chance the VM will be queried during a call (e.g. for debugging), otherwise just update the VM when you return control to it, the VM doesn't need to know the JITed code made other script calls.
3. see previous
4. skipped
5. The VMs stack frame pointer gives the base address and the stack pointer that gives the top of the stack, and instruction that accesses a stack will either use and offset from stack frame or update the stack pointer as values are pushed/popped onto the stack.
6. Registered value types larger than 64bit can potentially be stored on the stack.

Looking forward to seeing the progress on this. Currently only Blind-Mind's JIT compiler exists (as far as I know) and Blind-Mind is no longer updating it (though there are forked versions that are being updated by other users).

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!