In a way it feels somewhat silly to market a version of Lisp as targeting resource-constrained platforms, considering the systems it ran on back in the 1960s, but as time goes on, what would have given 1970s Big Iron a run for its money is now a sub-$5 microcontroller that you can run uLisp (MicroLisp) on. This particular project now even has an ARM assembler that is written in Lisp whose source code (GitHub) fits on a mere two A4-sized pages.
ULisp currently supports five platforms, being AVR-nano (ATmega328 and similar low-cost AVRs), AVR, ARM, ESP (8266 and 32), as well as RISC-V. The purpose of this assembler is to execute native ARM instructions when running on an ARM board, since uLisp itself runs a Lisp interpreter on the platform. When executed natively like this, a considerable speed-up of the task can be expected, as illustrated by a number of ARM assembler examples in the documentation.
Running a Fibonacci sequence that takes 24.6 seconds with the Lisp version on an Adafruit Metro M4 is reduced to a mere 61 ms when ARM assembly is used instead. This shouldn’t be too shocking, since this assembler essentially bypasses the Lisp runtime, coming closer to what would be the performance of firmware written in e.g. C. However, it also demonstrates that with this ARM assembler it is possible to have your Lisp and still get native performance when you want it, all using Lisp code.
” This particular project now even has an ARM assembler that is written in Lisp whose source code (GitHub) fits on a mere two A4-sized pages.”
Ah, the good old days when big things came in small packages. Now it’s small amounts in big packages.
Shrinkflation in all but documentation.
I remember UCSD-Lisp. The bad old day. :-D
Olaf
flashforth does this more efficently
flashforth.com
LISP??? Why lisp? Why not FORTH??? What language allows you to make major structural changes with ease.
Everything in LISP is a list. Want to change something? Just make a copy of its list with your changes.
Friend of mine used to do his prototype software in XLisp. He said that besides being faster to write prototypes in, the prototypes also ran faster than production code, but that was balanced by them also doing more things.
Love this… a collegue wrote a LISP interpreter on a 6800 in the early days of computing. Worked pretty good.
Any way you could contact that colleague and see if he still has the source and is willing to part with it?
https://guitarvydas.github.io/2021/06/08/Lisp-1.5-Memory.html
It is so good to know about uLisp! That deserves an article of its own! Hope to read it anytime soon!
uLisp is pretty cool, they even have an emacs SLIME server.
I’m working on a port for Zephyr RTOS here: https://github.com/jori-nordic/ulisp-zephyr/commits/master
Hoping to make an ok bluetooth API for it in the next few months.
I’ve used it and it’s a lot of fun.
The big win is the REPL.
You write and save code on the micro, and get a VERY fast feedback loop.