The idea behind this doc is to speedup the execution of sphere scripted triggers and functions. We can create a virtual CPU with a custom instruction set and compile the triggers / functions to that bytecode.
Pros:
Trigger / function execution speed up.
Change old recursive descent parser to a new LALR parser generated with Flex/Bison tools.
Prevent “reparse” issue on loops, recursive calls, etc.
Cons:
Rewrite parser, executer and write a virtual cpu (Too much work!)
Some instructions from current implementation can not be reproduced and has to be reworked (Basically, parsing in runtime). Instructions like:
On startup time, scripted functions and triggers are compiled to a byte code like format. All are stored together (code and static data like strings, we will see in depth this later).
On runtime, when a function or trigger is called, we call a scpu method, setting the arguments and call data and run it.
The method that runs the routine returns the status code of execution.
Compilation process:
Load scripted function to the parser (i recommend bison and flex generated parser).
Parser generates a tree from the source code.
Apply some optimizations to the tree (a visitor that constructs a new optimized tree).
Generate the byte code from the tree.
Add to the generated code an end instruction to return default value (for functions / triggers with no return).
Generate the static data from the symbol table.
When all the functions are compiled, we have to update call references to put the correct address.
All the functions / triggers are stored on the same memory, this allows us to do calls over other functions in a simple way.
SCPU Architecture
I recommend Harvard Architecture for simplicity.
User Registers:
A, General purpose, 32 bits.
B, General purpose, 32 bits.
PC, Program Counter, 32 bits.
FP, Frame Pointer, 32 bits.
SP, Stack Pointer, 32 bits.
COR, Current Object Reference, 32 bits. (UID from a Sphere object).
Can't we just integrate LuaJIT for the maximum speed and still support old scripting for compatibility reasons and sloooowly switch to LUA scripting in time :P ?
Sphere core processing unit
The idea behind this doc is to speedup the execution of sphere scripted triggers and functions. We can create a virtual CPU with a custom instruction set and compile the triggers / functions to that bytecode.
Pros:
Cons:
This has to change to:
We have to change:
Compilation process:
All the functions / triggers are stored on the same memory, this allows us to do calls over other functions in a simple way.
SCPU Architecture
I recommend Harvard Architecture for simplicity.
User Registers:
Internal Registers:
Memory:
Call procedure:
Ret procedure:
Init procedure:
Program Memory Organization:
Const Memory Organization:
Instruction Set
Waiting for community to continue work on this.
0x00000000 STOP
Stop execution. Get the A register value and transform to a valid return value and return it.
THIS IS A DRAFT