3 ms·

A random anecdote back in the early 90's I worked with a mad lad self taught non-degreed engineer. He did an embedded project where faced with memory constrain

A random anecdote back in the early 90's I worked with a mad lad self taught non-degreed engineer. He did an embedded project where faced with memory constraints based on unit cost. Ported a lisp interpreter to PIC assembly[1] and then write most of the code in lisp. Performance was about 1/2 to 1/5 that of straight C[2]. But the memory footprint was about 50% less. Which meant it fit into flash. He went on to use that for a few other products. [1] Took him three months to port it. [2] A 50% difference in speed usually doen't cause firmware to fail performance metrics.

jhgb 5y ago
Sounds like there's a decent chance that one could achieve similar things with something like Modula's M-code. Also compressing a large program into a small computer by having a part of the program written in compact interpreted code dates back at the very least to Apollo's Guidance Computer's INTERPRETER component.
- kragen 5y ago
  Compressing a large program into a small computer by having part of the program written in compact interpreted code dates back at least to Short Code on the UNIVAC I in 01950, which was "short" because it could fit six instructions per machine word instead of the usual two. Of course Turing's original hypothetical Universal Machine from 01936 is "universal" precisely because it is an interpreter that can emulate any computing machine, most importantly including itself, but you could reasonably object that Turing didn't actually build a working Universal Machine in the 01930s, and at any rate he wasn't concerned with the question of how to fit a lot of functionality into a small amount of RAM. I've seen references to "Turing's 'short code'" and to "ENIAC Short Code" but I am not sure if they are things that really existed or if someone was just getting their references confused.
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 ago
  The 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.

jhgb 5y ago

Sounds like there's a decent chance that one could achieve similar things with something like Modula's M-code. Also compressing a large program into a small computer by having a part of the program written in compact interpreted code dates back at the very least to Apollo's Guidance Computer's INTERPRETER component.

kragen 5y ago
Compressing a large program into a small computer by having part of the program written in compact interpreted code dates back at least to Short Code on the UNIVAC I in 01950, which was "short" because it could fit six instructions per machine word instead of the usual two. Of course Turing's original hypothetical Universal Machine from 01936 is "universal" precisely because it is an interpreter that can emulate any computing machine, most importantly including itself, but you could reasonably object that Turing didn't actually build a working Universal Machine in the 01930s, and at any rate he wasn't concerned with the question of how to fit a lot of functionality into a small amount of RAM. I've seen references to "Turing's 'short code'" and to "ENIAC Short Code" but I am not sure if they are things that really existed or if someone was just getting their references confused.

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 ago
The 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.