freenode/#sicl - IRC Chatlog
Search
7:36:36
no-defun-allowed
If squinting hard enough, HIR is fairly simple to translate to JVM instructions. Lexical locations and control flow at least are explicated in HIR, then memory in MIR, then register allocation in LIR.
8:12:15
beach
shka_: Cleavir proposes two (for now) intermediate representations that are independent of the implementation, i.e. AST and HIR. And it takes care of propagating source information from CSTs to ASTs to HIR. We can then supply transformations on those intermediate representations, in particular various optimizations.
8:13:33
beach
Yes, and as no-defun-allowed points out, for certain implementations, MIR and LIR could be useful as well. That is certainly the case for SICL.
8:14:11
shka_
ok, and at least parts of those transformations you mentioned are expected to be portable between concrete implementations, right?
8:14:53
beach
So Cleavir does not make anything easier than it is in any other implementation, but it makes it unnecessary for an implementation to do the stuff all over again.
8:16:09
beach
My secret hope (but I didn't believe it very much) was that existing implementations would replace their specific stuff with Cleavir stuff. But it certainly makes things easier for new implementations like Clasp, or the CLISP compiler that karlosz wrote, and now with a new compiler for ABCL.
8:17:49
beach
Maybe if some implementation has a compiler that is so hard to maintain, they might consider replacing it.
8:19:55
beach
So far so good. But we are not optimizing enough (yet). Bike and karlosz are working on it of course, so things will improve.
8:20:24
beach
For now, all we can claim is that there is less work involved to get a compiler up and running, than if they were to roll their own from scratch.
8:23:08
beach
And I chose an intermediate representation (HIR, MIR, LIR) that is similar to what most algorithms in the literature use, so many algorithms should be straightforward (but perhaps not easy) to implement.
8:28:39
beach
Over the years, I think we have understood many things about how to develop code that is as implementation-independent as possible, and that can also be customized for different clients. The way Eclector, Trucler, Clostrum, CST-to-AST, AST-to-HIR turned out, reflects this way of structuring code.
9:23:21
no-defun-allowed
ACTION tries to collect some function names while running a test and crashes SBCL in the process.
9:26:41
scymtym
no-defun-allowed: did you make sure not to reference dynamic-extent data outside of the context of the original thread?
9:27:42
no-defun-allowed
I don't think so, but I used dissect to give me a call stack and it produced a bogus object somehow (while in my thread interrupting code, so it should still be in context).
9:30:16
scymtym
there have been a few sb-sprof changes regarding e.g. pinning of code objects. maybe dissect does something that is longer safe. but i'm totally speculating
12:56:27
beach
I ran a small benchmark to compare the execution time of the AST evaluator to that of native code. So I compiled and ran the Ackermann function with arguments 3 and 11. With native SBCL it took around 1.3 seconds, and with the AST evaluator less than 6 seconds.
12:57:21
beach
I remember doing a short test in the past with the HIR interpreter, and it was a factor 10k slower than SBCL.
13:27:28
mseddon
wouldn't Ackermann bog down into a lot of huuuuge bigint arithmetic pretty quickly?
16:03:30
beach
I think what I came up with today is going to be great for allowing more "natural"-looking code. I defined a macro that, for an arbitrary form to be evaluated in some environment, I can selectively intercept calls to FUNCTION-CELL in that environment and return any cell I like, typically one from a different environment, but also one that I can construct on the fly.
16:03:38
beach
This mechanism will allow more flexibility as to which version of which function is defined in which environment. I can thus put functions in the environment that requires the fewest interceptions.
16:03:53
beach
Furthermore, I no longer need intermediate functions that I had to define just to avoid clobbering the definition of one version in an environment by the definition of a different version of the same function. As a result of all this additional flexibility, I can write the code so that it looks more "natural", without taking into account bootstrapping quirks, perhaps at all.
16:04:02
beach
It will also allow me to call DEFGENERIC, DEFMETHOD, DEFUN, and DEFCLASS in one environment, whereas now I have to define the accessor generic functions in one environment and the classes in a different one. This separation is not great in terms of maintainability and (again) it looks "unnatural".
16:07:50
beach
And, once again, I apologize for the current total lack of tools to explain these things to even the people with knowledge of SICL and Cleavir. I hope to come up with such tools some day. It may have to be soon-ish, because my presentations for the online Lisp meeting will have to contain some plausible (but simplified) explanation in the end.
16:21:24
beach
From the beginning, I took great pride in SICL code being "natural" looking, but in fact, the constraints of the existing bootstrapping technique made it quite a bit less "natural" than I would have wanted. Now, I can hopefully repair that problem.
16:23:21
jackdaniel
congrats, being able to make it look more like a "normal" Common Lisp program is certainly something -- it already looks like well on this axis
16:24:16
beach
Also, since my benchmark indicates that the AST evaluator is not horribly slow compared to host code, once I get this new bootstrapping technique up and running (assuming I can), I should also be able to remove some of the separation between macro definitions and their expanders. This separation seemed to be a necessity for bootstrapping performance and also for constraints on environments.
16:26:57
beach
Anyway, I should vanish in order to fix dinner for my (admittedly small) family. Tomorrow, I'll try to apply my new macro to phase 3 of a new bootstrapping technique.