VM Runtime Management

Parent Previous Next

VM Runtime Management.

The SCRAMBLECODE DLL can have multiple VMs instantiated at the same time.


API Functions




Each VM must load the bytecode to be executed. Typically the bytecode is loaded as a simple string but it can also be imported from a compilation unit file in debug situations.

The first VM in a DLL is always created by the host application using the DLL API, however a running VM can execute bytecode that initiates instantiation of other VMs.


When we refer to a VM as being instantiated, it actually means, that the DLL has been given an order to create a VM. This order either origins from the host or from another VM.

It is the DLL that owns the VM - it is not owned by the party that initiates the creation - and it can be shared among all instantiated VMs and the host.

Example: VMA may create VMB and VMC. The bytecode for the new VMs are just simple string constants in the VMA bytecode. Once creation is complete the new VMs are accessible to both VMA and the host.

The Life and Death of a VM.

A VM has this 3 step life cycle:

In bytecode these steps are accomplished by the library functions @VMCreate, @VMExecute and @VMFree. The DLL API have similar capabilities and provides analog functionality.

Here is an example of how to create and execute a VM:

 Public Function Foo(String bytecode) : Integer


   Integer vm, mainResult;

   //Create a new VM - getting a vm-handle to it.

   vm := @VMCreate(bytecode);

   //Insert values into these cells:

   // Row Col Value

   //  0   0   101

   //  0   1   0xF899A1EE

   @VMCellSetInteger(vm, 0, 0, 101);

   @VMCellSetBytes(vm, 0, 1, 0xF899A1EE);

   //Call the Main function of the new VM.

   mainResult := @VMExecute(vm, 0, 0, 0);

   //Destroy the VM.


   Return mainResult;


Notice how we in this example transfer data to the cells of the created VM before invoking the execution. Cells could also be used to read the results of an execution - before the VM is destroyed.