simon/naegling
simon/naegling
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Added all the error codes from the manual.

Browse source 
Some will be irrelevant to this project, but they're all here.
This commit is contained in:
Simon Brooke 2026-04-06 12:47:41 +01:00
parent 882f991db4
commit 643d255a21
3 changed files with 65 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

13
README.md
View file

@ -60,3 +60,16 @@ Tags will be allocated as follows:
| 7 | 119 | | unassigned |
| 7 | 127 | 0x7f | a free cell |
## Problems with building a Ghuloum-style compiler in Lisp 1.5
Ghuloum's compiler emits strings in the form of assembly language statements into a file which is then run through a separate assembler to produce a binary which is finally integrated with a launcher stub written in C using a linker. This makes it possible to write a Lisp largely in that Lisp itself (provided you have an existing Lisp fostermother image to run the initial compilation); but it does not dirctly enable you to compile a single function into the existing image at runtime, and then immediately use the newly compiled function; and as far as I'm concerned, until you have that you don't have a working Lisp compiler.
Furthermore, Lisp 1.5 does not have a concept of a string, and cannot manipulate strings. I *could* add strings as an extension, but that feels somewhat outwith the scope of this project.
I don't feel that any of this is insuperable. Lisp 1.5 supports the functions `PRINT`, `PRIN1`, and `TERPRI` which respectively make it possible to print complete S-expressions, individual atoms, and linefeeds. It would be possible to create a symbol whose print name was a single blank space. It would be perverse, and annoying, and `READ` would not recognise such a symbol so if it were included in a sysout file that sysout could not be read back in; but it would be possible.
Or else, we could assemble the assembly language statements as a list of individual S-expressions, print that, run it through an external preprocessor and the assembler, and then link the resulting binary. It does not seem to me that using an external pre-processor is any more 'cheating' than using an external assembler.
But finally, and this will be my preferred outcome, one could create that list of assembly language statements in memory; one could estimate from it the size of the compiled function; one could malloc a block of memory of that size on the heap; and one could then assemble the function by writing bytes into that block of memory as specified in the assembly language statements.
If I'm going to use this side-project as an exercise to learn how to write the Post Scarcity compiler, the Post Scarcity compiler has got to be able to do that; so I should try.