[virtmach] bytecodes and stacks

[Mark W. Humphries]

-----Original Message-----
From: Ceri Storey <cez@nomorespam.freeserve.co.uk>
To: virtmach@iecc.com <virtmach@iecc.com>
Date: Wednesday, December 01, 1999 4:59 AM
Subject: Re: [virtmach] bytecodes and stacks


> personally, i can't see why why two stacks would be a better solution,
> since when the machine returns from a function, the arguments bound
> in that procedure will be lost forever, and if a two stack model were
> used, the virtual machine/ programmer would need to pop the excess data
> from the data stack. also, i intend to have a calling convention
> somewhat like continuations in scheme, where instead of doing a 'ret',
> you apply the continuation, with the return value as an argument,
> hence the continuation will be just another piece of data. The garbage
> collection may get a little hairy, (the closed-over variables etc) but
> then again I'll just write it on top of guile, and use their gc. :)


The assumption is that each function/subroutine consumes (pops) its own
parameters from the vm data stack, and pushes its results to the vm data
stack. This is the traditional stack machine model, independent of source
language.

You're intermediate code is "bridging the semantic gap" at a higher level
than I.
An interpreter implementation consists of a compilation engine (possibly
interactive) which accepts source and lays down corresponding intermediate
(virtual) instructions, and an execution engine which "executes" the
intermediate instructions. The "semantic gap" is the distance between the
intermediate (virtual machine) instruction set and the implied semantics of
the source language. The wider the gap, the simpler and more generic your
execution engine, but the more complex your compilation engine. And
vice-versa, of course.
The extreme cases being on one end a direct execution architecture, and on
the other a real as opposed to virtual machine instruction set (native code
compilation/JIT compilation).

Cheers,
 Mark W. Humphries