Embedded Basic Interpreter

Apr 02, 2006 22 Replies

Would you be so kind as to write a paragraph or so explaining the overall structure of it? I imagine that some bits would just be a big CASE with BASIC statement X creating sequence of assembly language instructions Y, but there are BASIC statements that don't fit that mold.

If the footprint of the interpreter is critical, you may want to consider C-SLang

formatting link
It doesn't use its own RAM and ROM footprint is ~2K compiled for ARM. It was originally designed for "off-board" downloadable diagnostic modules but may fit your needs, too. The bad news is that the code in C-SLang looks like assembler. The good news is that C-SLang code is just odd-looking C data, so (a) the bytecode is produced by a C compiler and (b) you can #define sequences of instructions as function-like C macros.

Best,

- Ark

the overall structure of it? I imagine that some bits would just be a big CASE with BASIC statement X creating sequence of assembly language instructions Y, but there are BASIC statements that don't fit that mold.

I currently have the system broken up into 3 components:

  1. The Basic Compiler which parses the input and stages ASM like opcodes into a buffer. The VM has only 2 registers A and X.

A sample basic program:

int a

for a = 1 to 10 print a next end

compiles to:

Header Prolog Grow Stack 1 Move constant '1' to A Dec A Move Ato variable 'a' (SF offset 0) Move constant '10' to A Push A L0: Move constant '1' to A Push A Move variable 'a' (SF offset 0) to A Add TOS to A Move Ato variable 'a' (SF offset 0) Compare TOS with A without popping value from stack Set A if compare was GE Branch to L1 if false

Move variable 'a' (SF offset 0) to A Print A Print String Branch to L0

L1: Subtract Primary from TOS End

Don't analyze the output too closely. It's from an old version which didn't work correctly but it included it so you could get the idea.

Not that this is an english langauge dump of the opcodes I use to verify the compiler is working.

  1. The opcodes are sent to a byte code compiler that converts opcodes to a byte stream then resolves all lables.

  1. The VM takes the bytes codes and uses a great big switch statement based on the current byte code.

I did have to do a little bit of a hack because I want some special functions such as

pin(1) = 1 and a = pin(1)

In the first case pin is handled as a keyword while in the second case, I modified the assignment function to look for pin(x).

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required