There's something even better for the Raspberry Pi (2B only at the moment) - interim OS, a bare metal Lisp by Lukas Hartmann of MNT Research, the creator of the MNT Reform laptop.
The original site seems to be unavailable right now, but it's mirrored on archive.org:
In general, I find that s-expressions are actually a nice syntax for assembly languages. For x86, they kind of sidestep the AT&T vs. Intel conundrum, and you get to write macro-like functions in the host Lisp that compile down to s-expressions.
In their twilight years Symbolics implemented their own DEC Alpha assembler in Common Lisp to aid the development of their Lisp machine emulator: http://pt.withy.org/publications/VLM.html
You can still find its leaked source code on the internet.
"We built a prototype of the emulator in C, but it quickly became obvious that we could not achieve the level of performance desired in C. Examination of code emitted by the C compiler showed it took very poor advantage of the Alpha's dual-issue capabilities. A second implementation was done in Alpha assembly language and is the basis for the current product.
We built a number of tools (in Lisp, running on Genera) that supported the level of complexity of the assembly language program we were attempting. A translator was built that allowed us to use Lisp as a macro language. One of the primary benefits of using Lisp was that we could use all our normal development tools, including incremental patching, even though we were working in another machine's assembly language. Even more beneficial, however, was that early on in the project, we were able to easily graft on to the translator a cycle-counting tool that allowed one to easily and automatically "preview" any code fragment and see its total cycle cost, dual-issues that were taken or missed, and any free stall slots. Because this tool was integrated directly with the Genera editor, we were able to pro-actively optimize our code, right from the start. The full paper describes this tool in more detail, with examples, and compares it with tools that have recently become available from DEC that attempt to automatically re-organize executable files. It is our claim that our tool, because of its interactive nature, offers many more opportunities for optimization."
Reminds me of the predecessor for this 6502 assembler: https://www.pagetable.com/?p=848 -- the comments include a note by the author, Chip Morningstar of Habitat, saying the Lisp assembler was terribly slow on a VAX.
In their earlier years, the Symbolics 3600 series machines included a Motorola 68K series Front End Processor (the "FEP") for booting the main processor. And the assembler for that was written in Lisp.
At LCSI we had assemblers and debugging tools for 6502, x86 and others written in LMI Lisp, which we used to create several popular commercial versions of Logo.
A lot of lisps end up writing their own assemblers, the lisp model of 80/20ing your own compiler with every compiler step being a different set of s-expressions as sorts of intermediate representations works best holistically. On the old lisp machines even the microcode source would be specific s-expressions that as a final pass would be converted into the actual bit pattern needed by the machine.
This paradigm is well seen in the GOAL (Game Oriented Assembly Lisp) code for Jak & Daxter that could mix relatively standard lisp, MIPS asm, and PS2 custom vector asm all within the same function: https://web.archive.org/web/20070127022728/http://lists.midn...
Thank you for the explanation about the microcode. Many years ago, someone was explaining to me that Lisp machines were Lisp “all the way down”. There were no layers that you couldn’t reprogram with Lisp. When pressed for details, he claimed that even the band gap potential in the transistors of the machine could be reprogrammed, because the transistors were just an abstraction over more Lisp.
In the early days the CPUs had loadable microcode. With new operating system versions came language extensions for Lisp. Then one also got a new version of the microcode, which then had been extended for, say, inclusion of an instruction for OOP method dispatch. One also could compile some code to microcode.
Later the CPUs were actually Microprocessors (from TI and Symbolics). At least for the Symbolics Ivory microprocessor, the microcode no longer was loadable.
don't forget that besides microcode much of the lisp machine logic was implemented with PALs, which were themselves programmed in Lisp. the simple gates, mixers and flip-flops were describe with lisp code, so that the logic could be tested on the lisp machine. I don't know if they built the test tables using the lisp code, or wrote them out manually, but you essentially had multiple sources of truth that could be mutually verified: lisp code, test tables, and the behavior of the specific PAL.
33 comments
[ 3.5 ms ] story [ 86.3 ms ] threadhttps://github.com/marcpaq/arpilisp
The original site seems to be unavailable right now, but it's mirrored on archive.org:
https://web.archive.org/web/20230331151459/http://interim-os...
https://github.com/nathell/lithium/blob/master/src/lithium/a...
In general, I find that s-expressions are actually a nice syntax for assembly languages. For x86, they kind of sidestep the AT&T vs. Intel conundrum, and you get to write macro-like functions in the host Lisp that compile down to s-expressions.
https://gcc.gnu.org/onlinedocs/gccint/RTL.html
You can still find its leaked source code on the internet.
"We built a prototype of the emulator in C, but it quickly became obvious that we could not achieve the level of performance desired in C. Examination of code emitted by the C compiler showed it took very poor advantage of the Alpha's dual-issue capabilities. A second implementation was done in Alpha assembly language and is the basis for the current product.
We built a number of tools (in Lisp, running on Genera) that supported the level of complexity of the assembly language program we were attempting. A translator was built that allowed us to use Lisp as a macro language. One of the primary benefits of using Lisp was that we could use all our normal development tools, including incremental patching, even though we were working in another machine's assembly language. Even more beneficial, however, was that early on in the project, we were able to easily graft on to the translator a cycle-counting tool that allowed one to easily and automatically "preview" any code fragment and see its total cycle cost, dual-issues that were taken or missed, and any free stall slots. Because this tool was integrated directly with the Genera editor, we were able to pro-actively optimize our code, right from the start. The full paper describes this tool in more detail, with examples, and compares it with tools that have recently become available from DEC that attempt to automatically re-organize executable files. It is our claim that our tool, because of its interactive nature, offers many more opportunities for optimization."
Clozure CL should also include an inline assembler.
Lisp assemblers date back to the 60s.
This paradigm is well seen in the GOAL (Game Oriented Assembly Lisp) code for Jak & Daxter that could mix relatively standard lisp, MIPS asm, and PS2 custom vector asm all within the same function: https://web.archive.org/web/20070127022728/http://lists.midn...
Your explanation makes far more sense.
Later the CPUs were actually Microprocessors (from TI and Symbolics). At least for the Symbolics Ivory microprocessor, the microcode no longer was loadable.
The turns the world does instead of adopting good ideas from the get go.
http://pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-cod...
E.g. look at the defarmlap function definitions in Clozure Common Lisp:
https://github.com/Clozure/ccl/blob/master/level-0/ARM/arm-h...
.. and other files, plus other architectures in other subdirectories.