freenode/#sicl - IRC Chatlog
Search
7:46:32
beach
The boot procedure finishes successfully with the explicit argument-processing code!!!!
8:00:43
beach
Now, I can again think about HIR-to-MIR. For the initial executable, I initially thought I would simplify the argument-passing convention, but with this explicit argument-processing code, I don't think I have to do that. The only slight complication in MIR, or even later in LIR, is that I may have to insert a loop that moves all the arguments on the stack in order to make room for the lexical variables. But that loop is pretty
8:02:23
beach
In fact, if I keep the convention final convention I planned, the instruction COMPUTE-ARGUMENT-COUNT is trivial, because the argument count is in one of the registers.
8:13:36
beach
heisig: And again, thank you for making me think harder about argument processing in HIR.
8:14:38
beach
I still need to document that code, since it is incomprehensible. I'll just refer to the specification which I think is fairly clear.
8:15:24
heisig
I'm working on trucler-native this morning. Which is also interesting because it forces me to examine the Trucler protocol very closely.
8:16:01
beach
Since you are at it, consider what stuff (code and documentation) should be moved to the reference implementation.
8:17:16
heisig
For example, when working on SBCL environments, I realized that the low-level augmentation functions are really only useful for trucler-reference.
8:18:34
heisig
Oh, and something I wanted to ask - the CLTL function AUGMENT-ENVIRONMENT can add any number of bindings and declarations simultaneously. Why did you decide against that?
8:22:20
beach
I decided against the entire CLtL2 protocol because it is not extensible and can not be customized, and that is because it does not use generic functions.
8:26:26
heisig
The problem right now is that each call to add-[lexical-variable,variable-type,variable-ignore,...] returns a new environment.
8:27:23
heisig
But when translating a single LET-binding with three variables and a few declarations, we allocate more than a dozen new environments.
8:27:43
heisig
Which sounds wasteful. It may not be a problem for SICL, but other clients might have other desires.
8:30:18
heisig
That would be my suggestion. Or, even better, not a macro but functions for creating an 'environment-builder', and for turning an environment-builder into an environment.
8:30:56
heisig
Then all the ADD-* functions could still be generic, but would work on such an opaque object.
8:32:55
heisig
And a final remark - I'd like to add a predicate NULL-LEXICAL-ENVIRONMENT-P to Trucler. Does that sound reasonable?
9:48:36
beach
So for HIR-to-MIR, I want to process each function at a time, except that I don't want to process the top-level function at all. After closure conversion, the functions in a compilation unit are almost entirely independent. The only dependency is that the ENCLOSE-INSTRUCTION refers to some ENTER-INSTRUCTION. The ENCLOSE-INSTRUCTION will be translated to a call to allocate a function object, and the reference to the ENTER-INSTRUCTION
9:48:37
beach
will ultimately be replaced by an entry point, which is an index into a byte vector that contains native instructions.
9:51:39
beach
I should probably also import the idea from Cleavir1 where the ENCLOSE-INSTRUCTION is separate from the instruction that sets the static environment.
10:01:34
beach
Aside from those considerations, I think HIR-to-MIR is sufficiently complete as it is.
12:59:46
heisig
I just created a Github organization 'sicl-developers', where we could collect all SICL related repositories (as scymtym suggested).
13:00:46
heisig
beach: You should have received an invitation to become one of the owners of this organization.
13:02:39
heisig
Owner is a slight misnomer, because the real owner of all Github projects is Microsoft...
13:04:52
heisig
Unfortunately, the name 'SICL' was already taken. But I have contacted that person, maybe he is willing to change his account name.
13:14:44
heisig
I am also tempted to change the description of the organization to 'X Implementors of Common Lisp', for X being some sensible adjective starting with S.
13:23:43
beach
heisig: I also have no preference, but I know scymtym is thinking in much more general terms than SICL.
13:24:32
heisig
Right. Maybe we should wait for feedback from scymtym before we make any next steps.
13:30:23
beach
Like, scymtym is working on things like a module that defines many characteristics of every Common Lisp special form, including syntax, indentation, etc.