An ARM Assembler Written in Lisp(forum.ulisp.com)
forum.ulisp.com
An ARM Assembler Written in Lisp
http://forum.ulisp.com/t/an-arm-assembler-written-in-lisp/1237
33 comments
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.
Your explanation makes far more sense.
Your explanation makes far more sense.
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.
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.
Ironically we are back to loaded microcode and memory tagging.
The turns the world does instead of adopting good ideas from the get go.
The turns the world does instead of adopting good ideas from the get go.
What kind of memory tagging are you referring to? I can think of W^X, but I don't see how well it compares to lisp stuff.
Also seen in the nanopass compiler framework: http://nanopass.org/
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."
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."
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.
The Genera code for ARM64 and Intel 86-64 is also written that way.
Clozure CL should also include an inline assembler.
Lisp assemblers date back to the 60s.
Clozure CL should also include an inline assembler.
Lisp assemblers date back to the 60s.
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.
I once wrote a rudimentary x86 assembler in about 250 lines of Clojure:
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://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.
doesn't clang use a sexp like notation for some IR ?
GCC’s RTL does
https://gcc.gnu.org/onlinedocs/gccint/RTL.html
https://gcc.gnu.org/onlinedocs/gccint/RTL.html
Clang's ir is more c like. I can't find a link to a good example offhand, but if you pass the right combinations of flags to clang you can dump it.
To rub salt in Stallman's wounds.
SBCL: the ultimate assembly code breadboard (2014):
http://pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-cod...
http://pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-cod...
And here's a Lisp written in ARM Assembler :)
https://github.com/marcpaq/arpilisp
https://github.com/marcpaq/arpilisp
So the base components of a future Lisp Machine are available. :)
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:
https://web.archive.org/web/20230331151459/http://interim-os...
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...
[deleted]
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.
Major Lisp implementations have things like this.
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.
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.
Factor (a modern stack language) has assemblers for x86 and PowerPC (last I checked), and should be easy to also incorporate ARM.
RISC-V next?
SBCL has been ported to RISC-V, so it has an assembler for that architecture.
[deleted]
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...