Re: Bytecode Compiler

Nils M Holm <>
28 Apr 2004 15:19:41 -0400

          From comp.compilers

Related articles
Bytecode Compiler (2004-04-21)
Re: Bytecode Compiler (2004-04-28)
Re: Bytecode Compiler (Nils M Holm) (2004-04-28)
Re: Bytecode Compiler (=?ISO-8859-1?Q?Cass=E9_Hugues?=) (2004-04-28)
Re: Bytecode Compiler (2004-04-28)
Re: Bytecode Compiler (2004-04-29)
Re: Bytecode Compiler (A Pietu Pohjalainen) (2004-05-02)
Re: Bytecode Compiler (Paul Robinson) (2004-05-24)
| List of all articles for this month |

From: Nils M Holm <>
Newsgroups: comp.compilers
Date: 28 Apr 2004 15:19:41 -0400
Organization: Compilers Central
References: 04-04-064
Keywords: code, interpreter
Posted-Date: 28 Apr 2004 15:19:41 EDT

Chris Cranford <> wrote:
> Then, I need to come up with a set of opcodes which permit working with
> memory pointers, right?

Here is the definition of a working bytecode machine that basically
implements the ideas you have outlined in your article:

However, the machine uses separate text and data segments. When a
program is loaded instructions creating strings like


are removed from the text segment and the data defined by it are
copied to the data segment. To load a reference to a string on the
TOS, you would use

DLAB 99 create label '99' in data segment
STR 5 H E L L O define string
LDLAB 99 load address associated with label '99'

Since you are implementing a stack machine, most operations expect
operands on the TOS. This is similar to a RISC architecture which
expects operands in registers. All you need is a set of load/store
operations to move operands from registers/stack to memory and
vice versa.

For example, A := B+C would code as follows (assuming A is a global
variable stored in the data segment at label '27', B is local at
stack frame position 2 (FP+2) and C is at FP+3):

LDL 2 load B
LDL 3 load C
SAVG 27 save to A

Global storage is allocated by defining labels at compile time.
A statement like

VAR X[5], Y[7];

in a global context would create code like this:

DLAB 25 some label
DATA 5 allocate five data cells
DLAB 26 another label
DATA 7 allocate seven data cells

To allocate local storage, the compiler has to create instructions
to move the stack pointer, as you already have suggested. Allocating
X[5] locally would move the (push down) stack pointer down five
words and freeing it would move the pointer up. The compiler must
keep track of stack frame positions in order to emit the proper
'load local' and 'save local' instructions.

This is all described in detail in the manual mentioned above.

BTW, The T3X compiler package contains a compiler generating the
bytecode described above plus a bytecode loader, optimizer,
disassembler and some other tools. Feel free to download it at:


Nils M Holm <> --

Post a followup to this message

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