I read this earlier today:

• https://eli.thegreenplace.net/2017/adventures-in-jit-compilation-part-1-an-interpreter/
  • 4 parts total.

There were some neat ideas about optimization, specifically trying to create opcodes/IR for "[-]", etc. Rather than just interpreting token by token.

This might be worth exploring, though remember I will need to update three places:

• - asm-backend
• - C-backend
• - interpreter-backend

In the past we generated C source file, and compiled via gcc.

Then we swithced to generating assembly language source, compiling via nasm.

We should allow both. Add a "backend" and let the user choose which to run.

Just means updating the assembly language.

At the moment bogus input will cause problems. We kinda assume things are well-formed, because we're very naive.

If we wanted to be robust we should implement a lexer/parser, and work on tokens. We could then add error-handling, proper test-cases, etc, etc.

• This would make the code bigger.
• It would allow us to support both C and Assembly language output though.

Not a huge priority, but I guess I could take a look at it in the near future.

Since we have plugabble back-ends it might be nice to have a simple interpreter implemented as one.

It kinda defeats the point of us being a compiler but it also demonstrates the speedup gained by actually compiling.

Add a -breakpoint/-debug flag, which will cause int 03 to be generated in the compiled program when present.

See my math-compiler for discussion:

https://github.com/skx/math-compiler#debugging-the-generated-programs