freenode/#sicl - IRC Chatlog
Search
6:54:47
beach
I made several improvements to the figures showing argument processing: Chapter 25 of metamodular.com/SICL/sicl-specification.pdf
6:56:22
beach
I fixed a bug whereby the REST parameter was not initialized if during the initialization of optional parameters, it was discovered that there were no more arguments.
6:57:58
beach
And I changed the order of the successors of some fixnum comparison instructions so that I could use an instruction class that actually exists.
7:00:59
beach
Like, FIXNUM-NOT-LESS does not exist, because one can always use FIXNUM-NOT-GREATER with reversed arguments or FIXNUM-LESS with reversed successors.
7:06:09
beach
Hmm, so that means that I could remove FIXNUM-NOT-GREATER as well, because one can always use FIXNUM-LESS with reversed inputs and reversed successors.
7:07:44
beach
And if the argument is "well, it doesn't hurt to have it", then why not include FIXNUM-GREATER and FIXNUM-NOT-LESS as well.
7:10:37
beach
The situation with ASTs is different, because one can not swap the inputs of an AST without changing the order of evaluation, but for instructions, the evaluation order is explicit in the control graph.
8:54:10
beach
Here is the current plan for the near future, and I would like opinions about it, especially if I have planned something stupid:
8:55:01
beach
I implement the Common Lisp code to add those HIR snippets for argument processing and I apply that code early on after AST-to-HIR.
8:56:02
beach
I already have most of the code to translate from HIR to MIR. There might be a few corner cases left,
8:57:03
beach
MIR has explicit address calculations, but target-specific stuff like registers have not yet been introduced.
8:59:28
beach
However, to avoid writing the register allocator, I give every lexical location and every raw datum its own place in the stack frame.
9:00:41
beach
A few registers are reserved as scratch registers to hold lexical locations and raw data temporarily in order to execute an instruction.
9:02:28
beach
So an instruction will be translated into several LIR instructions. Each input will be loaded into a register, and the instruction will compute its outputs in registers, and finally, the output registers are saved to the designated locations of the locations on the stack.
9:03:43
beach
What is left to decide is how to represent the dynamic environment, and things like how to handle unwinding.
9:05:29
beach
After that, I use the assembler I wrote in order to turn the linearized LIR code into a byte vector of native instructions.
9:49:09
beach
In fact, now that I know how easy it is to create a simple executable file, I should play around some more with the assembler. There are definitely instructions that I haven't defined and that will be needed early on.
14:07:07
beach
The assembler seems to work. I was able to write the same program as I did to test the ELF executable, except I wrote it using my assembler. And I had to add SYSCALL to the instruction database, which worked fine. I can execute the resulting program with the desired effect.
14:07:38
beach
But when I looked at the output of the assembler and compared it to the output of NASM, I was puzzled.
14:08:38
beach
In NASM I wrote "mov rax, 60" and "mov rdi, 44" and it seems to generate instructions that only assign to the 32-bit half of those registers.
14:11:44
beach
The code generated by my assembler uses the REX prefix and a full 64-bit constant. That's a bit wasteful, but it is no doubt because I haven't encoded all variations on the MOV instruction in my database.