ZCrypt

Object based

Allow creation of "native" objects/classes.
Handled partly at the assembler level, partly at compiler level.
VM stack will have a current object register, for "this".
To handle functions (as opposed to methods) have a default object, that is used as a placeholder.
Inheritance?

Make it more dynamic

Make it easier to compile from source at runtime.
More "introspection" operations. e.g. querying for available methods/fields
Functions/Methods will be called by name and number of arguments. i.e. late binding.
Allow functions to be called dynamically. i.e. from programmically created strings.

Easier to integrate with java

Java objects can be treated as "native" objects. Use reflection classes to find public methods and fields.
Allow new'ing of java objects?
Allow calling of static java methods?
Allow inheritence from java objects?

Misc

Bootstrap from java. i.e. use java classes to do things, rather than re-invent the wheel.
Use java.lang.String objects, so we do not have to write own substring etc functions.
Provide builtin arrays and hashes.
Various arithematic operators: + - * / ^
VM state can be saved/loaded.
Attempt to keep size small.
Make use of java to do heavy lifting.
Assembler/VM should only be written once. i.e. when a new instruction is added they should not need to be changed. The new instruction class will deal with loading/parsing itself.
Compiler will interface with assembler via text. i.e. Compiler outputs assembly instructions.

Implementation

Instruction Interface

public interface Instruction {

/** Get the assembly language mnenomic for this instruction. **/

public String getMnenomic();

/** Get the op code, ie the instructions id. **/

public int getOpCode();

/** Get a new instance of this instruction class. **/

public Instruction newInstruction();

/** Initialize the instruction, with arguments from the assembler.**/

public void parse( Object[] args ) throws ParseException;

/** Read any extra data the instruction requires.**/

public void readData( DataInput in, Hashtable stringTable ) throws IOException;

/** Write any extra data the instruction uses. **/

public void writeData( DataOutput out, Hashtable stringTable ) throws IOException;

/** Execute the instruction. **/

public void execute( VirtualMachine vm );

}

Using this the assembler would function something like:

read line of text

read mnenomic

find instruction that matches mnenomic

parse numbers/strings etc after mnenomic

pass them to a new instance of the instruction

write out instructions op code

get instruction to output its data

repeat until done

The VM will load instructions something like this:

read op code (a byte)

find instruction that matches op code

make a new instance of the instruction

get the instruction to read in its data

repeat until done

In both case the finding of the appropriate instruction will be handled by some "other" class. This class could then either dynamically work out what instructions are available, or simply maintain an array of instructions. In both cases the maintanence of the assembler/vm is easier. At least in terms of adding new instructions. There is then also less chance of mismatches, as all of the data is being kept in one place (inside the instruction classes).

Instructions

Instructions operate on the stack. In general if a variable has not been initialised it will return yield the value "null". This goes for array and hashes, as well as fields on objects.

Many instructions depend on certain values being present on the stack when they are called. Values will usually be popped from the stack in reverse order. Where a and b are referred to, usually b is popped then a.

NOP

PUSH number | string | boolean | null

POP # pop a value and discard it

COPY # pop a value and push two copies of it onto stack

CLEAR_STACK # clear the current stack

JMP instruction # jump to instruction

JMPF instruction # pop a value and jump to instruction if false

TYPE # pop value, push values "type"

ADD # a + b

MINUS # a - b

NEG # -a

MUL # a * b

DIV # a / b

MOD # a % b

POW # a ^ b

AND # a and b

OR # a or b

XOR # (a or b) and not (a and b)

NOT # not a

EQ # a equals b

NEQ # not a equals b

GT # a > b

GTE # a >= b

LT # a < b

LTE # a <= b

GET_LOCAL var # put local var on the stack

SET_LOCAL var # take value off stack and put in local var

GET_GLOBAL var # same for global

SET_GLOBAL var # same for global

ARRAY # make a new array, initialised with values from stack (first popped denotes how many values).

GET_ARRAY # pop an index then an array and push value back on

SET_ARRAY # pop a value, an index then an array. Set value at index

APPEND # pop value, then array, add value to end of array

HASH # push a new hash onto the stack

GET_HASH # pop a key, then a hash from stack, push value

SET_HASH # pop value, key and hash. Set value for key

KEYS # pop a hash, push an array of its keys

OBJECT # pop num args, args and class name. Pushes new object.

THIS # push the current object

CALL_METHOD # pop num args, args, method name and object from stack and calls method, pushing result (or null if no result).

GET_FIELD # pop field name and object, push field value

SET_FIELD # pop value, field name and object. Set value for field.

CALL_METHOD

Pops (in this order) num args, args, method name and object from the stack. method name and num args will be used to find out which method to call. Additionally when calling methods on java objects the args may have to be used too, with some coercion into different datatypes.

If object is null (and it may be) then the search for a method begins with the object "this". If no match is found then the search will procede to the functions defined. In this way we can remove the requirement for placing "this" in front of internal method calls, but also still allow the calling of functions from within a method. e.g.

class MyClass {

method myMethod() {

someOtherMethod(); # calling a method

someFunction(); # calling a function

doSomething(); # could be either

}

method someOtherMethod() {

}

function someFunction() {

}

Stack Frame

The stack frame will look something like:

frame

this # ref to current object

localVars # local variables array

methodName # current method name

numArgs # num of args

currentInstruction # the instruction being executed

Functions

Functions are like methods, but they are associated with the VMs environment. As with methods they are dynamic and called by CALL_METHOD. In this way it should make it easy to extend the builtin functions. To so this simply extend a VMEnvironment object and pass that to the VM. This will be queried for additional functions. User defined functions will supercede builtin functions, and are effectively methods on an extended version of the VMEnvironment object.