Ah, Lisp, the archaic language that just keeps on giving. You either love or hate it, but you’ll never stop it. [David Johnson-Davies] is clearly in the love it camp and, to that end, has produced a fair number of tools wedging this language into all kinds of nooks and crannies. The particular nook in question is the RISC-V ISA, with their Lisp-to-RISC-V compiler. This project leads on from their RISC-V assembler by allowing a Lisp function to be compiled directly to assembly and then deployed as callable, provided you stick to the supported language subset, that is!
The fun thing is—you guessed it—it’s written in Lisp. In fact, both projects are pure Lisp and can be run on the uLisp core and deployed onto your microcontroller of choice. Because who wouldn’t want to compile Lisp on a Lisp machine? To add to the fun, [David] created a previous project targeting ARM, so you’ve got even fewer excuses for not being able to access this. If you’ve managed to get your paws on the new Raspberry Pi Pico-2, then you can take your pick and run Lisp on either core type and still compile to native.
The Lisp-Risc-V project can be found in this GitHub repo, with the other tools easy enough to locate.
We see a fair few Lisp projects on these pages. Here’s another bare metal Lisp implementation using AVR. And how many lines of code does it take to implement Lisp anyway? The answer is 42 200 lines of C, to be exact.
Operative word is “subset” I guess. Full-fat lisp isn’t compilable, in part because of it’s tendency to be self-modifying.
You could always write a full fat lisp interpreter on it….
That would be slow.
Yes it is relatively slow. But a 150MHz 32-bit RISC is pretty quick compared to the 68K systems a lot of the big Lisp interpreters were running on back in the day.
For running small utilities and control programs in a single threaded environment, you don’t need a lot of performance.
And even with low performance you could write something pretty sophisticated like a home weather station that does a little statistical analysis to try and predict the weather.
I can run C on the same microcontroller. But I wouldn’t normally have a C compiler (I bet porting c4 to it would be straight forward). And I wouldn’t have a POSIX OS on that microcontroller either, and the OS and system libraries is a good portion of what we normally expect from C. Anything less starts to look like a subset. If I don’t have sockets and can’t compile NodeJS, then is my C-on-a-microcontroller just a less useful subset.
I think the same reasoning applies to Lisp as it does to my C example.
There’s a fair amount of optimization possible if you have a decent Common Lisp implementation (compiler or interpreter) running on top of a sufficiently featured subset of Lisp. Compilers of fatter lisps should be possible in that case, until the poor Pico-2 runs out of RAM.
one cool thing that is happening is there are projects like qemu bridging the gap between emulation and compilation. so it’s not only “theoretically possible” to use compilation against self-modifying code, it’s something that is actually happening with some regularity now.
What are you talking about? Almost all Lisp implementations are compiled. Scheme is even designed for separate compilation (unlike the usually image-based Common Lisp). Yes, you need to carry the compiler with your runtime in order to support
evaland alike, but that’s not too much of an overhead.so why didn’t RISCV replace ARM?
Why past tense? RISC-V is far too new.
Arm has been around for 39 years (32 bit) or 12 years (64 bit).
The first RISC-V spec suitable for microcontrollers or embedded Linux was ratified and published just over 5 years ago in July 2019, and indeed RISC-V has already taken over much of the embedded market (new projects … obviously people don’t rip Arm out of already-designed stuff).
The first RISC-V spec suitable for desktop PCs / laptops / smartphones / tablets RVA22(+V) was published just over 2 years ago in July 2022, though hardware powerful enough to satisfy most people in those roles won’t be arriving for 1-2 more years (SG2380 might do the job), and most will probably end up as the not yet quite ratified RVA23 (will be next month).
In 1994, you’d have asked “so why didn’t ARM replace the Intel 8051?”
Come back in 20 years and ask.
I wish these articles would stop this slack usage of “Lisp machine”.
ChrysaLisp supports RiscV64, x64, Arm64 and VP64 emu.
System build times under 0.2s on your average laptop.
RiscV64 backend in 425 lines of code.
Available on GitHub for free. Videos of demos on my YouTube page.
Lisps time is yet to come :)
Chris Hinsley
Well, for me, Lisp time is come … and gone. It fact, I can’t even see it in the rear view mirror — so to speak :) . Sticking with assembly, C, and Python for majority of my programming with some Perl, Pascal, and Rust thrown in.
That said, pretty neat you got it working. lisp compiler written in lisp.
Lisp (historically LISP, an abbreviation of “list processing”) is a family of programming languages with a long history and a distinctive, fully parenthesized prefix notation. Originally specified in the late 1950s, it is the second-oldest high-level programming language still in common use, after Fortran.[1]
[One] Lisp
https://en.wikipedia.org/wiki/Lisp_(programming_language)
I remember finding a copy of “The Little LISPer” in the university library long ago. Very interesting but I have never really had a need to use it. Except for the occasional tweaking of my .emacsrc.
Some time ago some information was published on the patch that had to be applied to software running on a CDP1802 in the Galileo spacecraft. The old MicroForth develepment system was long gone so the patch was accomplished using LISP. I am not sure why that was the tool used but it worked.
https://github.com/rongarret/gll-mag-patch/