freenode/#sicl - IRC Chatlog
Search
14:37:50
Bike
there are basically two places you need something like a phi node- for if, and for block. as far as i can tell. this was really obvious in my rewrite, but i'll have to work something out in the existing code.
14:40:06
beach
There is a paper that generates SSA directly from AST or some other similar representation, but I decided Cleavir couldn't use it because of the fact that it generates code from the end. And this is to get the evaluation context right.
14:41:23
Bike
Yeah I mean we definitely can't generate everything in SSA right off, because we can't force everything to be SSA at all, because of closures. So that's off the table.
15:01:35
beach
Suppose you wanted to create a Linux executable with a huge data structure already built inside it, like a Common Lisp implementation for instance. And suppose you want it to be able to handle ASLR. As I understand it, SBCL did that at some point. Wouldn't you basically have to mark every Common Lisp datum as relocatable, assign a symbolic name to it, and have the dynamic linker fix it up at startup time?
15:07:11
scymtym
i don't think the platform's linker can help. in sbcl, relocating the heap is basically a full gc, if i remember correctly
15:09:54
scymtym
so i'm generating that would be more complicated than relocating yourself. at least if you already have a moving gc
15:15:31
beach
Here is another question, also more philosophical than practical: It used to be the case that a global variable in C was just an address. Now, because of dynamic linking, they use a mechanism that introduces many more memory accesses (GOT tables and whatnot). We don't have that problem in Common Lisp, so could a Linux executable use a mechanism closer to that used for Common Lisp, rather than this GOT business?
15:18:37
beach
But I started thinking about it, because flip214 gave me feedback on the CLOSOS specification.
15:19:29
scymtym
part of the problem seems to be that C doesn't have a "runtime" that could make adjustments when new code is loaded. and the linker doesn't know enough about the program to do it
15:20:05
beach
That's a clue though. But doesn't C++ require a way more complicated linker these days?
15:20:39
beach
And in the CLOSOS specification, I discuss problems with existing operating systems in there, so ASLR came up. And that got me thinking about things that have become more complex because of shared libraries, etc.
15:22:30
beach
I guess the C++ linker is still not active at run time, and that could be a requirement for a more sane mechanism.
15:25:28
scymtym
in #sbcl, pfdietz just mentioned a paper in which C++ code is significantly sped up by optimizing at runtime :)
15:25:52
Bike
c++ causes exciting things like two modules having code for the same macroexpanded (template) function definition
15:26:12
Bike
i asked about it on twitter once and the compiler people i know started talking about drinking
15:30:14
pfdietz
The big win is moving cold code away from hot code, and grouping the hot code together, to reduce pressure on the instruction cache.
15:34:17
beach
I would think the code would be so close that it would fit in a cache line to have any effect.
15:37:53
beach
It used to be the case that a cache line was a few words long, and that the cache line was chosen for some memory chunk based on the address modulo the size of the cache.