Re: Bytecode Compiler

Chris Cranford wrote:
> Or, I could simply this to permit NULL bytes in the stream by using
something
> like:
>
> OPCODE [2 byte length] 54 65 73 74
>
> Or another alternative approach would be a special opcode that tells the VM
to
> go to a special block of storage in the BYTECODE file known as the DATA
BLOCK
> and extract X number of bytes and store these in memory and also push the
> memory pointer on the stack.
>
> OPCODE [2 byte length] [2 byte data block offset]
>
> DATA BLOCK
> ----------
> Address # 0000 : 54657374 00000000 00000000 00000000
> Address # 0020 : 00000000 00000000 00000000 00000000
> ...


      This last solution sounds better because it will allows sharing
constant strings between many stirng creation.


>
> So the associated opcode would be: [OPCODE 00 04 00 00]
>
> Now, once the memory pointer has been placed on the TOS, there would be
then
> an opcode that tells the VM to store the TOS in the local variable space of
> the stack frame at offset 0.
>
> pstore_0 // Stores TOS in local variable slot 0 (s) [for pointers]
> pload_0 // Loads local variable slot 0 (s) into TOS [for pointers]
>
> Then, I need to come up with a set of opcodes which permit working with
memory
> pointers, right?


      I think that your main problem is that you do not have designed the
memory map of the VM execution, nor the representation of code units: is
your program formed by a lonely executable or is there many units
working together. In any case, you must have an idea how to serialized
the program on the disk.
      Once you have a code unit, you must choose how it is organized. The
original P-Code from Wirth has memory map including constant segments
(for integers, real and strings). The P-Code included also special
instructions for accessing constant area.
      This method avoids the burden of straight memory accesses that may
cause system errors hard to handle during the inetrpretation. Java
byte-code is another good example of avoiding straight memory pointer:
any memory access is either a constant access, or a object access: in
any case, the real address computation is ensured by the VM and so no
invalid memory can be accessed. .NET/CLOS does not provide such
facilities because it must support C programs that allows uncontrolled
access to the memory.
      A last information: you must decide how you will handle basic data
types: if integers and real are easily managed, handling strings and
arrays in basic may involves some garbage collecting facilities. As an
example (bas, I think), the Wirth P-Code VM provides the memory
allocation as an incremented pointer on a memory area but memory release
was not available making really easier the memory management.


      Have fun in the world of VM.


      Hugues Cassé

Return to the comp.compilers page.
Search the comp.compilers archives again.