freenode/#sicl - IRC Chatlog
Search
5:50:32
beach
Question of the day: Can I represent target closures in the host in such a way that I can generate target code from them?
5:51:56
beach
I mean, I can certainly represent them in the host. They are just data structures after all.
5:52:35
beach
So when such code is executed in the host, I definitely won't get the target representation of a closure.
5:53:43
beach
If I can't represent target closures in the host, I need to generate code that creates those closures when the initial native executable starts up.
5:55:37
beach
I do have control over the (Cleavir) compiler though, so if I can convince it to generate code that creates a target representation of a closure in addition to a host closure, I can do it.
5:56:53
beach
Recall that in the host, I turn HIR into host Common Lisp, so I have ENCLOSE instructions in there. I wonder whether that's enough information to create a target representation of the closure being created.
6:06:42
beach
Once I have a code generator, I will turn a HIR program into two different things in the host: 1. What I do now, namely a host function that can be executed as usal in the host 2. A "code object" containing native instructions.
6:13:16
beach
Then I can turn the ENCLOSE instruction into host code that creates an object that is used in the host to represent a target object, namely a header and a rack. The header is a host FUNCALLABLE-STANDARD-OBJECT so I can do a (SET-FUNCALLABLE-INSTANCE-FUNCTION ...) to make it executable in the host, and I can do a (MAKE-INSTANCE 'HEADER ...) to create the representation of the target closure.
6:16:12
beach
Another thing related to bootstrapping. Currently, DEFUN generates a host function and so does DEFMETHOD for the METHOD-FUNCTION. That's incorrect. It should be one of those host FUNCALLABLE-STANDARD-OBJECT instances containing both a host function and a representation of a target function.
6:20:37
beach
Hmm, I guess they are all the same. All those functions are generated as a result of executing (the translation of) an ENCLOSE instruction. So modifying the host code generated from those instructions should handle it.
8:39:47
beach
There is of course no way I will have time to implement all this before the ELS deadline.
9:04:46
heisig
beach: The more I think of it, the more I like the idea of representing all code in a FASL or image as an AST.
9:07:07
beach
But the code object would not have any explicit representation in the AST. It would be the result of applying AST-to-HIR, HIR-to-MIR, MIR-to-LIR.
9:13:08
heisig
Why is that so? Wouldn't it be sufficient to have function AST's in the code object slot and do the other steps at load time?
9:17:42
beach
I'm lost. Here is the idea: The file compiler takes the CST and converts it to an AST. Then it writes the printed representation of the AST to the FASL file. End of story. When the loader loads the FASL file, it does the remaining compilation. It turns the AST into HIR into LIR into machine code. And the machine code is what makes up the code object. The result of the compilation is a single top-level function that takes some
9:17:43
beach
arguments specific to the environment, perhaps the environment itself. The code is "tied" to the environment by calling this top-level function.
9:19:43
beach
So the FASL is essentially the result of "minimal compilation" as defined in the Common Lisp HyperSpec.
9:22:55
heisig
But to do so, you need a full code generator. That is why I thought that one could, at least for the ELS '19 paper, represent each code object as an AST and use SBCL+Cleavir as the loader.
9:24:27
beach
I don't know about cheating, but I also don't see how that would make the paper more acceptable to the referees.
9:25:25
beach
It would be a cute way of making it possible for people to try out SICL before it exists. That's for sure.
10:03:52
beach
Aside from this years paper submissions, it looks to me like I should work on code generation next.