Original Post
Hello! I know the topic of JITs have been up on the table before, but I couldn't find any details concerning actually implementing one. This is mostly directed to you, Andreas, but as this is information that will interest others wanting to add a JIT/AOT compilation for their processor of choice, I choose to post this here (and in English!) rather than emailing you directly. I started playing around with AOT compiling for AS as a fun sparetime project to get to know the ARM architecture a bit better. But before I get too deep into the actual implementation (and would have to rewrite the whole shebang to fit with your ideas) I figured I'd ask you what your thoughts are when it comes to JIT/AOT compiling and how it all would hook into the AngelScript engine. I think writing a JIT/AOT compiler is a big project to take on unless you can split it out into chunks and take it one step at a time. As such, one of the features I'm interested in is to be able to mix native machine code with AS bytecode and switch between them. Thus I suggest a new AS bytecode instruction is implemented "JIT" (or something else, but I'll use that name from now on). I've not thought this through 100% so the actual implementation will likely change during the course of the work on this. But my current idea is that the "JIT" bytecode would:
- if JIT is enabled:
- save l_bc, l_sp, l_fp to the context
- Call "ExecuteJIT(this, machineCode)",
where "this" is the asCContext and "machineCode" is a pointer to
the array containing the native code to execute (where this code
buffer is actually stored is to be decided...)
- load l_bc_l_sp,l_fp from the context
- else:
- nopint TestBasic(int a, int b, int c)
{
return a + b * c;
}Temps: 1
0 0 * PUSH 1
- 3,5 -
1 1 * SUSPEND
2 0 JIT 0 ; Notice the new instruction
3 1 * MULi v1, v-1, v-2
5 1 * ADDi v1, v0, v1
7 1 * CpyVtoR4 v1
8 1 * 0:
8 0 * RET 3
0xe92d4030 stmdb sp!, {r4, r5, lr} ; Prologue
; Save return pointer and scratched
; registers we are required to save on
; the (native) stack
0xe5902028 ldr r2, [r0, #0x28] ; Load AS's stack frame pointer from the asCContext
0xe5921004 ldr r1, [r2, #0x4] ; Load v-1
0xe5923008 ldr r3, [r2, #0x8] ; Load v-2
0xe0040391 mul r4, r1, r3 ; Perform the multiplication
0xe5925000 ldr r5, [r2] ; Load v0
0xe0854004 add r4, r5, r4 ; Perform the add
; Epilogue
; Here at this code we notice that we don't support the next AS bytecode
; As such we need to flush any changed data and return from the code
;
; If on the other hand the next opcode would also have been supported, we
; would have continued executing even further and would not write any data
; back until it is needed, either by running out of native registers to
; use, or when it is time to exit
0xe5024004 str r4, [r2, #-0x4] ; Save v1 to the stack as it changed
0xe5904020 ldr r4, [r0, #0x20] ; Load byteCode pointer from the context
0xe2844014 add r4, r4, #0x14 ; Add the number of AS bytecode data to
; skip (includes the JIT instruction)
0xe5804020 str r4, [r0, #0x20] ; Save back to the context
0xe8bd8030 ldmia sp!, {r4, r5, pc} ; Restore scratched registers we had to
; save (according to the ARM calling
; convention) and return (by setting
; pc = lr)
