Re: Implementing a stack-based interpreter

On Sun, 17 Jul 2005 13:52:46 -0400, cvrebert wrote:




> I'm trying write an interpreter for a programming language but haven't
> been able to find anything on how to write a stack-based interpreter.


* Trick one, don't reinvent the wheel. There are quite a few simple stack
machines out there, compile to one of them. (If suitable.)


So if you have decided on making your own custom, slightly off round
wheel...


* Trick Two. Don't make up your destination stack language
first. Write your compiler to stack language first. As you try
implement each syntactic element, invent whatever stack primitives
that will magically do the job for you.


* Trick Three. Don't do it all in your own language. The average real
CPU machine instruction is very simple, very dumb, with lots of fiddly
special purpose registers and addressing modes.


This simply doesn't hold with a stack based interpretor. Keep
addressing modes dead simple. Everything is on the stack. No
registers.


However, if you are writing your own custom language, odds on its
_very_ domain specific. So why not implement the occasional
instruction that is really very smart? It's a trade off, a big fat
function in your interpreted language translated into lots and lots of
dumb operators, or a few very very smart operators written in lots and
lots of C++ or C or what ever you are using.


The one I did had freaky vaguely fuzzy/flow sorts of
variables. Instead of implementing operations on them in terms of lots
and lots of basic integer / floating point ops... I created a few very
highlevel ops that did most of the work in C++. Much Faster, Much
simpler.


Hint.


Think very hard about dataflow and ownership of objects and
memory. Memory leaks abound if you don't. Use a GC'd implementation
language if you can.
--


John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand

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