Assembler Interpreter for microcontrollers – sane?

I’m thinking of how much work it would be to write an assembler interpreter in PIC assembler. Probably sounds like the dumbest idea in the world, right ;-)

I’ve been toying with this idea lately for sort of futureproofing microcontroller-based designs, and adding some new possibilities for specific applications (polymorphic / self-modifying code, security applications, Arduino shields with their own drivers built in, etc.). Basically, the ability to load executable code from some arbitrary source and run it from RAM, the way we’re used to with general-purpose computers. The key problem in this idea of course is that typical microcontrollers can only execute code from their internal Flash memory, not RAM. There are few hacks out there that straddle the line between bootloading and execution, e.g. load code from (arbitrary source) and write it to an unused block of Flash, then execute it, then load some more code over it, etc., but this could wear out Flash memory pretty quickly. The only way to execute something directly from RAM is if it’s an interpreted language. Rolling my own interpretive language and its interpreter in ASM doesn’t sound like much fun, let alone getting anyone else to adopt it. It seems like the “least-work” approach would be for the interpreter to take its input in the form of MCU opcodes directly, looking them up in a jump table and executing the corresponding instruction from Flash ROM. That avoids having to write your own language and some complicated parser for it, and documentation for the language, and debugging tools, and…

This simplistic explanation works for basic operations (register reads and writes; you could use this to bitbang some new piece of hardware on the GPIO pins that didn’t exist when you released your gadget), but breaks down a bit when dealing with handling calls/gotos and code addresses, and where to safely stash all the interpreted code’s variables. I think I need to put a bit more baking into this idea for that reason, but it seems mildly promising so far.

(And no, I’m evidently not the first person to have this idea. When searching to see if someone had already done it, no working implementations, but Michael Millikan mentions a similar idea on PICList (see Mar 3 2004 entry).