Virtual machine opcode format

Opcodes are formed by exactly fuor bytes.

The first byte is the Op code ID, and uniquely identifies the instruction that must be performed. The remaining three bytes are the operator type an can be:

• 00H - not used
• 01H - an immediate integer (32 bit)
• 02H - a string ID (32 bit)
• 03H - an immediate double value (64 bit)
• 04H - an immediate NIL value
• 05H - an immediate 64 bit integer
• 06H - Variable ID in the global table
• 07H - Variable ID in the local table
• 08H - Variable ID in the parameter table
• 09H - Reserved for external symbol load
• 0AH - a string ID representing a late binding
• 0BH - True
• 0CH - False
• 0EH - 32 bit not to be decoded
• 0FH - 64 bit not to be decoded
• 10H - register A - Accumulator
• 11H - register B - Extra
• 12H - register S1 - self
• 14H - register L1 - first latch (accessed item)
• 15H - register L2 - second latch (accessor item)

The paramters immediately follow the opcode and are stored in little endian order, if being integer, or directly in float format if being double. If the relative parameter indicator is 0E or 0F the PC is moved accordingly, but the paramters are left undecoded; this is useful for instructions that take a fixed parameter type to avoid variable encoding/decoding. Otherwise, the parameter are decoded and stored in the VM volatile registers OP1, OP2 and OP3 depending on their position.

In example, a CALL 3, $func, where $func is stored in the global variable table at ID 15H, look like this in hex:

   3A 0E 05 00   03 00 00 00   15 00 00 00

The first 3A is the CALL opcode, then a 0E ordering the VM not to read the first parameter (which will be handled directly by the CALL handler), but just to skip 32 bits, then the 05 informing the VM that OP2 is a variable in the global table, and the 00 indicating that there's no third parameter. This is followed by "3" and "15H", both stored in big endian order. The VM won't fill 0P1 register, while it will fill OP2 with an integer item containing 15H.