freenode/#sicl - IRC Chatlog
Search
19:22:50
alandipert
is there a term in the compiler terminology lexicon for a target code "scaffold" or "template?" ie a general pattern parameterized by local information
19:23:40
alandipert
sort of like an ASM macro but specialized and emitted by a compiler and not a person
21:27:03
alandipert
got a new major draft of my ELS paper together with expanded commentary (3.3.3) on TAGBODY compilation. thanks in advance for sharing your thoughts! https://tailrecursion.com/~alan/documents/jacl-els-2020-draft.pdf
4:17:23
beach
alandipert: I was with my (admittedly small) family last night when you asked your questions.
4:19:06
beach
I'll also read your paper, but it might be after you submit it though. It is usually possible to upload a modified version.
4:19:26
beach
And you definitely have the opportunity to include changes as a result of the referee reports.
4:21:39
alandipert
beach maybe it's such an obvious thing so as to not require a special term. but an example in my case would be the generic structure of the javascript i generate for TAGBODY, for example
4:22:14
alandipert
2 particular javascript variables with gensymed names, followed by a try/catch with a switch in it, etc. and most of this is static but particular elements are generated at the "site"
4:23:20
beach
I am not aware of a name for that. In Cleavir, that's just a method on a generic function.
4:26:12
beach
In other words, we have no explicit representation for the template. It is just encoded in the method that turns the code into an AST.
4:27:19
beach
A Cleavir AST is very close to the source code, but the compile-time environment is no longer needed, so macros have been expanded, etc.
4:29:33
alandipert
hm, i think i'm either confused or not describing what i'm thinking clearly enough
4:31:40
beach
Maybe you are talking about the JavaScript code which is mostly constant, but only a few things to fill in?
4:31:43
alandipert
a simpler example that comes to mind is the way, generally, "if" statements compile to jumps in assembly- there is a consisent, abstract shape to the generated code: conditional jump, followed by a branch, label, other branch
4:32:18
alandipert
err, usually an unconditional jump past the second branch in that case. so: test, branch, jump, label, branch
4:34:03
beach
Such a thing would be useful only in a very simple compiler, though. Normally, you would first translate the IF into a graph representation. Then you would have a large number of transformations and optimizations before you generate assembly code. By the time you do that, the connection between the original IF and any tests and conditional jumps would be gone.
4:35:51
alandipert
that's fair, but there's still ultimately a specific mapping between an IR node a human designed and the target code, yes? i suppose that's more specifically what i'm talking about
4:37:30
alandipert
i guess it really is a continuum and that last link in the chain isn't special, provided enough transformations
4:38:17
beach
Sure, but in a typical compiler that mapping would be fairly trivial. The IR node would be something like ADD with two successors, one for not-overflow and another for overflow. Whether one branch or the other is the target of a conditional branch would not be encoded in the IR.
4:40:11
beach
For example, in SICL, I have a pass to turn the final LIR (Low-level IR) into a sequence. Code generation then checks whether the next instruction in the sequence is a graph successor and if not, generates a jump.
4:42:24
beach
HIR is a graph that manipulates only Common Lisp objects, which is good for certain transformations.
4:42:55
beach
MIR exposes address calculations, and with that, addresses that are not Common Lisp objects. That level lends itself to another bag of transformations.
4:43:01
alandipert
i think my strange perspective is definitely becuase i'm basically going from AST to AST
4:44:41
alandipert
but there is some art in mapping constructs from CL to JS optimally, which i find myself enjoying
4:49:50
beach
Hmm, now that I think about it, MIR would be the place to stop in order to generate code in a low-level language like C, and HIR would be the place in order to generate code in a high-level language like JS. In fact, I already turn HIR into Common Lisp for the purpose of executing it in the host.
4:53:15
alandipert
like a year ago i read an old post from jonathan rees on CMU CL AI mailing list and he pointed out that most GOs can compile to local jumps, which stewed in my brain for awhile until it occurred to me that could work in JS thanks to some obscure goto-like JS features
4:56:50
alandipert
on that list there was some related discussion about compiling tagbody with catch and throw, which was highly relevant to me, since those have JS analogues
4:57:40
alandipert
the catch/throw way is the simplest and most general, but incurs the most runtime overhead. turned out this is how JSCL (previous JS lisp) does it always
4:58:10
alandipert
anyway cutting to the chase, i'm wondering if it's true to say that one can statically determine whether or not every GO is "local", for a given TAGBODY
4:58:45
alandipert
i say as much in my paper, but i haven't done it myself yet, and appreciate confirmation :-)
4:59:32
alandipert
i second guessed myself recently when i was messing with SBCL and it appeared to not explode when i captured GO tags in LAMBDAs from one TAGBODY and then invoked the lambda in the dynamic extent of another TAGBODY with a tag of the same name
4:59:36
beach
You would use some kind of context when you compile, and that context would reflect whether you are in the same dynamic environment in the TAGBODY and the GO.
5:01:14
alandipert
is it correct to think about tags like locals? ie they don't exist at runtime, effectively
5:01:57
alandipert
a lexical variable reference... that its name is immaterial, only its identity with respect to its environment is important
5:03:22
beach
So if the GO is in the same dynamic environment as the TAGBODY, which you can determine statically, then a jump is all you need.
5:04:29
alandipert
great. i have a plan for the local case that performs very well, but the ability to determine statically that a TAGBODY has no dynamic GOs allows me to emit less code
5:04:48
alandipert
i'm generally not interested in code size optimization except that which google closure compiler wouldn't know how to eliminate
5:35:35
beach
alandipert: But the thing is that a non-local GO can be turned into a local one after optimization...
5:36:38
beach
But escape analysis may reveal that the static environment inside the LET can not be captured, so you can inline the function call.