freenode/#clasp - IRC Chatlog
Search
4:53:36
drmeister
cclasp (the Cleavir compiler in Clasp with first class top level environments) compiling the cclasp code.
4:55:14
drmeister
Bike is setting things up so that macro definitions and whatnot modify the compile-time environment but not the runtime environment. So compiling cclasp with cclasp can not damage the running compiler. But the new definitions for macros and symbol macros and everything else will be used in the compilation.
4:56:09
drmeister
It gives us the kind of protection that sbcl gets with tricky package manipulation.
4:57:52
beach
And I thought that idea was rejected because it was too hard to set up a Clasp environment in SBCL. Not that I understand why.
4:59:00
drmeister
Everything that cclasp needs from the C++ is summarized in a few data structures. We can generate that from a quick run of a script in the Clasp interpreter - and then give that to a full cclasp compiler to generate bitcode for a new cclasp compiler.
5:00:29
drmeister
So 15 min to compile the C++ code, 15 min for a cclasp to compile another cclasp based on the configuration from the C++ code and then a few min to link the C++ bitcode with the CL bitcode.
5:01:24
drmeister
And we might be able to get the configuration info out of the C++ source code so that we can compile the C++ code in parallel with the CL code.
5:02:45
drmeister
Then we can apply optimizations that right now run afoul of the bootstrapping system.
5:08:45
beach
If you introduce a defect at some point, and that defect goes unnoticed for a few generations of bootstrapping, it is sometimes impossible to get back to a correct version.
5:10:22
beach
I don't have any universal method. I used that in the compiler I wrote for my theses, and never found a good way out, other than being extremely careful. That is why, for SICL, I only require a full working Common Lisp implementation plus the MOP.
5:11:07
drmeister
So - once we have it working for Clasp - Bike want's to extend it to sbcl and other Common Lisp compilers.
5:12:10
beach
But then, you lose the advantage you said: "It's much less work to do it with cclasp than it is with sbcl."
5:12:11
drmeister
In that approach we have a backend that generates an intermediate representation that the C++ interpreter would use to generate llvm bitcode.
5:13:07
drmeister
I see it more as an evolution. We can get something up using cclasp and then migrate it to sbcl by writing this backend.
5:15:13
drmeister
Then the build system becomes (1) extract the configuration info from the C++ code (2) compile the Common Lisp code using sbcl -> generate S-expressions that describe the intermediate representation (3) Run code in the Clasp interpreter that translates the intermediate representation to llvm-IR and generate bitcode (4) link the CL bitcode with the C++ bitcode.
5:16:51
drmeister
The configuration info includes things like the stamp values of all of the C++ classes.
5:18:31
drmeister
These are almost all of the constants that the CL code needs to know to generate code that works with the runtime in C++.
5:24:03
drmeister
Bike is the one that impressed on me that we want to run this in sbcl as soon as possible.
13:40:59
Bike
beach: i changed my mind about sbcl being too hard. it's still work, but it seems preferable to the current system, or to relying on having a previous clasp binary
13:41:21
Bike
i haven't started on it, though. we'll have to rewrite the source so that it's written more conformingly
13:43:07
Bike
i also think we can probably have the cleavir-in-sbcl thing only go to ASTs and not bother with HIR, unless i'm missing something
13:45:19
Bike
i'm hoping after some time we can strip things down so that the interpreter knows how to load fasls and call C++ and not much else, so we can have things defined in CL instead of C++. but that's farther off
13:53:37
beach
I think going from source code (or CST) to AST is the hard part, because the environment must contain all the implementation-specific macros, types, etc.
13:54:04
beach
From AST to HIR should be easier. There could be some specialization on the implementation, but it shouldn't be too hard.
13:59:26
Bike
I have some functions set up that make an environment for cleavir that only has the functions available in the interpreter, plus cleavir primops and such. It has a cleavir-env:eval method that evaluates things in a different global environment that has a full CL
14:58:52
drmeister
I presume that trace is binding *print-pretty* to T and the traces are unreadable because the lines are very, very long
15:02:52
Bike
(princ (with-output-to-string (*trace-output*) ...) *trace-output*) haha, what the fuck