murisi / l2 Goto Github PK

I've drastically changed the interface to the compiler. Will update the "Getting Started" section of the README to reflect the changes.

In bootstrapping an L2 compiler I suspect that we will need to be able to step through L2 code (the L2 code being used to implement the L2 compiler) in a debugger. I reckon this functionality shouldn't be too difficult to implement given how the compiler is currently implemented.

The L2 compiler works by compiling L2 code into assembly, and then sending the assembly code over to GNU assembler to be assembled (with the -g debugging flag set) into a binary, and then deleting the assembly files that were created.

So I am guessing that a debug option for the L2 compiler would be done by first not deleting these temporary assembly files. By doing this, an attachment of GNU debugger to an executable produced by the L2 compiler would be able to print the line of assembly causing the executable to crash.

The second thing that would need to be done to implement a debug option would be to make the L2 compiler comment the assembly code it emits with the L2 code it corresponds to. That way, somebody debugging an L2 program would be able to quickly contextualize the machine/assembly code causing the crash.

I got errors about stk_check_fail, fixed by adding the -fno-stack-protector flag

#!/usr/bin/env bash
mkdir -p bin

gcc -nostdlib --static -g -fno-stack-protector -c -o bin/x86_64_linux_interface.o bootstrap/x86_64_linux_interface.s
gcc -nostdlib --static -g -fno-stack-protector -o bin/l2compile bootstrap/compile.c bin/x86_64_linux_interface.o

Right now the L2 compiler by default only links its executables to glibc. This is going to be a problem in bootstrapping an L2 compiler because it will also want to be linked against libdl (which is used to allow the compiler to execute macros). So the shell interface needs to be extended/redone to support such a choice (which we will need when compiling the L2 compiler written in L2).

Any thoughts/implementations welcome.

I wrote the current L2 compiler in C because I thought that the L2 programming language would be very similar to C. Both languages are procedural, C's jmp_buf is L2's continuations, C's pointers are L2's references, and L2 can use most C libraries compiled for i386 Linux (glibc, libdl, ...).

Hence what needs to be done is to create a bootstrap directory that mirrors the src directory except everything would have a .l2 instead of a .c file extension. And then convert each C function in the src directory into an L2 function making macros to simplify the task as necessary (try to use macros as a last resort). Try not to do too much at once, and make sure that each L2 function made is tested (maybe by checking that the L2 compiler written in C with the function written in L2 linked in still passes all the tests?)

Transliterating the L2 compiler is the easiest usability test of L2 that I could think of. If you think different, comments are welcome. If you know a better way to do this, suggestions are welcome.

In bootstrapping an L2 compiler, I suspect that there may be a few regressions. Hence I am thinking of making a folder (probably called "test") with L2 source files with the command to compile them, and their expected outputs embedded into them as comments. That way, manually running tests is not as tedious as it is now. I'm guessing the L2 code in the reductions section should be sufficient to populate the "test" folder.

Any implementation, or any suggestions of a system better than this are welcome. Please know my bash scripting skills are very weak.

L2 does neither has a reference-of operator (an ampersand in C), nor the concept of L-values or of R-values; a symbol name alone refers to the symbol's address in memory. The downside to this setup is that symbols constantly have to be dereferenced. The main problem I have with this is that the current syntax for dereferencing, [' variable], is that it makes it harder to read the majority of expressions that I would expect to find in L2 code.

My idea is to make a macro that replaces all symbols within it beginning with an apostrophe, with a call to the dereference function on the rest of the symbol. That is, ''symbol123 gets replaced by [' [' symbol123]]. So I guess the macro (supposing it is called ') would work by changing ('(begin [set x 'y])) to (begin [set x [' y]]). I expect larger gains in readability for larger expressions.

Any thoughts/implementations welcome.

I got this error doing a self hosted build

$ ./build_selfhost 
/usr/bin/ld: list.o:(*IND*+0x0): multiple definition of `no symbol'
/usr/bin/ld: list.o:(*IND*+0x0): multiple definition of `no symbol'
/usr/bin/ld: list.o:(*IND*+0x0): multiple definition of `no symbol'
/usr/bin/ld: list.o:(*IND*+0x0): multiple definition of `no symbol'
/usr/bin/ld: list.o:(*IND*+0x0): multiple definition of `no symbol'
/usr/bin/ld: list.o:(*IND*+0x0): multiple definition of `no symbol'
/usr/bin/ld: list.o:(*IND*+0x0): multiple definition of `no symbol'
/usr/bin/ld: list.o:(*IND*+0x0): multiple definition of `no symbol'
/usr/bin/ld: list.o:(*IND*+0x0): multiple definition of `no symbol'
/usr/bin/ld: list.o:(*IND*+0x0): multiple definition of `no symbol'
/usr/bin/ld: list.o:(*IND*+0x0): multiple definition of `no symbol'
collect2: error: ld returned 1 exit status

I'm not sure how to fix it. I'm on 64 bit arch linux.

The string macro is used as follows (" word1 word2 ... wordN) where wordI is a string of characters. The problem with this setup is that it does not support the emission of control characters like newline or backspace. This will make bootstrapping an L2 compiler tedious in the part where it does string manipulation.

Hence I am thinking about either making the string macro recognize a sequence like "\b" and emit a corresponding ascii code 8. So (" Int\bside) becomes "Inside". Though this is what is done in a lot of languages, this does not feel too elegant.

An idea that I'm favoring is that when the string macro comes across as list s-expression (not a character s-expression), it should evaluate the expression and insert the resulting character into that position of the string. So expressions like (" Int(d 8)side) and (" Int[backspace]side) (where backspace is a nullary function evaluating to 8) evaluate to "Inside".

Any thoughts and/or implementation of them welcome.