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.