3 ms·
I've heard FORTH is also good for that kind of embedded higher level programming. The interpreter is probably simpler to implement than lisp.
by klipt 5y ago
I've heard FORTH is also good for that kind of embedded higher level programming. The interpreter is probably simpler to implement than lisp.
- kragen 5y agoThe traditional way to write such a Lisp interpreter is to compile the Lisp code to a somewhat FORTH-like stack machine. Elisp is done this way, for example; Smalltalk-80 is very similar. A typical Lisp bytecode is more compact than typical FORTH threaded code because most of the operations are one byte, and common operations are assigned several bytecodes. (For example, you might have four bytecodes for function invocation with no arguments, one argument, two arguments, and three or more arguments; the last one takes the argument count from the stack or from a separate byte in the instruction stream.) In ordinary FORTH threaded code, every operation is two bytes (or maybe four on a big computer), but you probably want to implement "token threading" if you're trying to do it on a PIC, which ends up being the same thing. That part of the interpreter, the part that's hard to implement because you're writing it in PIC assembly and want it to run fast while using a space-efficient encoding, almost can't tell whether you're writing FORTH or Lisp, because all it's interpreting is strings of stack bytecode. The big difference is the garbage collector: in FORTH you don't have one, normally. But you can write Lisp without a garbage collector, too, and if you're running on a PIC you probably want to do that.