freenode/#sicl - IRC Chatlog
Search
13:33:46
beach
I made good progress on register allocation today. I have a mysterious ENTER-INSTRUCTION that for some reason has not been processed so that it has explicit argument parsing, and it is not a TOP-LEVEL-ENTER-INSTRUCTION. This mysterious instruction has an output that is not taken into account in the initial register arrangement, so when I hit its successor (which requires the corresponding lexical location), it fails because that
13:35:39
heisig
ACTION was always confused by the distinction of ENTER-INSTRUCTIONs and TOP-LEVEL-ENTER-INSTRUCTIONs
13:37:55
beach
When a FASL file is loaded, it is turned into a function that, when called, executes the top-level forms in the initial code. That function results in an ENTER-INSTRUCTION as usual, but I need to (or at least I used to need) attach more stuff to it than is needed for a normal ENTER-INSTRUCTION.
13:38:29
beach
But now that you mention it, I don't think I need that stuff anymore, so maybe I don't use the TOP-LEVEL-ENTER-INSTRUCTION anymore.
13:39:30
beach
So perhaps it is a top-level ENTER-INSTRUCTION but not a TOP-LEVEL-ENTER-INSTRUCTION, which would explain why it has not had its arguments processed.
13:40:36
beach
I think I need to remind myself how I do the top-level processing these days, before I attempt any "fixes".
13:43:13
heisig
Yes, my gut feeling says there shouldn't be different kinds of enter instructions. Of course my gut feeling might be wrong.
13:44:26
beach
I think the information that I used to stash in the TOP-LEVEL-ENTER-INSTRUCTION is now in the code object. But, again, my bad memory does not remember all this. Hence the need to study what I did.
13:50:10
beach
OK, so it looks like the top-level ENTER-INSTRUCTION is not a TOP-LEVEL-ENTER-INSTRUCTION, and that this top-level ENTER-INSTRUCTION has not been processed for explicit argument processing (which may or may not be correct, I can't remember).
13:50:46
beach
And it does have a lambda list with a single required parameter which is also present in the outputs.
13:52:36
beach
I need to figure out 1. Why this top-level function has not had its argument processed like the nested ones do. 2. Whether the way it is, is deliberate or a bug. 3. What that parameter is about.
13:55:40
beach
If I think about it for a second, I think this top-level function is meant to be executed as native code, just like anything else, in which case it must be subject to explicit argument processing just like everything else.
14:18:43
beach
So in PROCESS-ARGUMENTS there is an explicit test that excludes the top-level ENTER-INSTRUCTION from having its arguments processed. That is a very plausible explanation as to why the argument processing wasn't done. :)
15:06:20
beach
If I process the arguments of the top-level ENTER-INSTRUCTION, the HIR evaluator complains about .UNBOUND. which probably means that I am not calling the top-level function right. But I am too tired to figure this out today. I'll settle for the progress I already made on register allocation.