![]() ![]() ![]() |
The goal of the
MABWA project
is to produce an implementation
of PyFL that is much faster than the current lazy interpreter,
that repeatedly decodes the expression tree.
The current interpreter produces Basic PyFL, with all the advanced
features (like while
loops) implemented by translation.
Our strategy is to translate Basic PyFL
into the machine language for a FORTH-like stack-based
abstract machine.
The MABWA machine has a conventional FORTH like design,
with a reverse polish instruction language.
To add 2 and 3 you push 2 then 3 on the implicit value stack,
then execute the add instruction that pops the top two elements of
the stack, adds them, then pushes the result on the stack.
The 'commands' begin
and end
delimit code blocks, sequences of instructions
that will be manipulated but not immediately executed.
The MABWA machine pushes these two blocks onto the stack
when it encounters them. They become the top two elements of
the stack.
The next stage is to assemble the MABWA code into machine language.
The result is still text, but at a lower level and more concise.
For example, addition is denoted by +
,
and load
becomes three instructions.
Here is the machine language that results when the above program is assembled (with two newlines added for readability):
(" x $ dup * " y $ dup * -) (" y $ 2 ** " x $ 2 ** -) " x $ " y $ < if sqrt
The machine language program is sent to the (machine language) interpreter, which interprets the program, but not in its textual form. The text is sent to a loader, that converts it to an internal form - nested arrays of strings. Each code block becomes an array of strings and instructions are looked up in a python dictionary. Definitions of variables are also stored in a dictionary along with cached values.
The pseudo-instruction
"
causes the
name of the variable (a string) to be pushed on the stack
without being examined
(as an instruction). Then the instruction
$
looks up the definition of the variable - a code block
(not shown) which is then executed.
Environments come into play during evaluation of function calls.
There are two environments, the environment in which the function was
called and that in which it was defined. The body of the
function is evaluated in the defining
environment but the actuals are evaluated in the calling environment.
We plan to write a test interpreter in Python to check out the
logic. But for speed, the ultimate goal, we'll use Apple's Swift.