Proposal: Compiled functions / triggers.

[roberpot]

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:

• 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:

LOCAL.T = <SRC.STR> + 1
SERV.LOG = <EVAL <LOCAL.T>>

This has to change to:

SERV.LOG = <EVAL <SRC.STR> + 1>

We have to change:

1. 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).
2. On runtime, when a function or trigger is called, we call a scpu method, setting the arguments and call data and run it.
3. The method that runs the routine returns the status code of execution.

Compilation process:

1. Load scripted function to the parser (i recommend bison and flex generated parser).
2. Parser generates a tree from the source code.
3. Apply some optimizations to the tree (a visitor that constructs a new optimized tree).
4. Generate the byte code from the tree.
5. Add to the generated code an end instruction to return default value (for functions / triggers with no return).
6. Generate the static data from the symbol table.
7. 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).
• IR, Instruction Register, 32 bits.
• F, Flags, 8 bits.

Internal Registers:

• AC, Arg counter, 8 bits. (to prevent invalid memory access).
• CC, Call Counter, 8 bits. (to preven infinite recursion).

Memory:

• Program memory: fixed size 32 bits memory. Fixed to the total memory required by the compiled functions and triggers.
• Data memory: 32 bits memory, 4096 bytes.
• Const string memory: fixed size 32 bits memory. Fixed to the total memory required by the const strings from compiled functions and triggers.

Call procedure:

1. Push FP to SP.
2. Push AC to SP.
3. Increment CC.
4. Add parameters on reverse order to the stack.
5. Add the return address to stack.
6. Set FP = SP.
7. Jump to the call address.

Ret procedure:

1. Set A with the return value.
2. Pop SP until local space is empty.
3. Pop SP to PC..
4. Pop parameters from SP.
5. Decrement CC.
6. Pop SP to AC.
7. Pop SP to FP.

Init procedure:

1. Search address from the called function / trigger and set PC to this address.
2. Push 0 to SP (false FP).
3. Push 0 to SP (false AC).
4. Push args to SP.
5. Set AC with argument count.
6. Push 0 to SP (return address from the first call).
7. Start.

Program Memory Organization:

• Address 0x00: STOP.
• Address 0x01: Start point of the first compiled function / trigger.
• Address 0xAA: End of the first compiled function / trigger.
• Address 0xAA+1: Start point of the next compiled function / trigger.
• …

Const Memory Organization:

• Address 0x00 - 0xAA: pointers to CGString constant values from first compiled function / trigger.
• Address 0xAA+1 - 0xBB: pointers to CGString constant values from next compiled function / trigger.
• …

  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

[denizsokmen]

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 ?