Not looked at OPs code, but if you build this stuff how a compiler book tells you to... The front end of a interpreter and a compiler is the same. You build a AST, if you interpret you well interpret that. If you have a compiler, the AST is turned into the target language, in most cases asm. The front end is the scanner/Lexer, the parser and most likely semantic analyser. So to answer you question :), if you make a non optimizing compiler, turning the AST into asm is trivial. The hard part of making compilers is the optimization. Most of the front end you do not need to write actually! There are compiler-compilers for that.

https://en.wikipedia.org/wiki/Abstract_syntax_tree

https://en.wikipedia.org/wiki/Compiler#Front_end

https://en.wikipedia.org/wiki/Lexical_analysis

https://en.wikipedia.org/wiki/Parsing

https://en.wikipedia.org/wiki/Semantic_analysis_%28compilers...

In fact, you can write a naïve interpreter or compiler completely in lex and yacc :)

Depends what you compile to. Writing a register allocator may be a little tricky (if you compile to a VM/Assembly/..), though if you compile to something like C, it's very easy. LLVM is another alternative which is also relatively simple to learn.

Spilling every variable to memory isn't too bad if you just want it to work and aren't worried about performance.

Linear scan register allocation is "good enough" in most cases and it is trivial if you're doing it on top of an SSA.

Compilers are in general far simpler than interpreters, especially if you're trying to build an interpreter with a reasonable performance.

For a simple language compiler is nothing more than a chain "parse -> strip off syntax sugar -> resolve lexical scope -> propagate types -> flatten the code -> emit target code", with each step being independent and trivial, nothing more than a set of tree rewrite rules.