libera/#sicl - IRC Chatlog
Search
3:57:06
beach
I was thinking yesterday about how literals are accessed from native code. Maclina uses a vector of literals, and I guess I hadn't considered that possibility, though that might be what mainstream Common Lisp implementations do for native code.
3:58:31
beach
But that would be quite expensive for an ordinary function call. Whether you use the symbol as an indirection as I suppose most Common Lisp implementations do, or whether you use the "cell" indirection as we do with Clostrum, the symbol or the cell would be considered a literal that must be accessed.
3:59:07
beach
So if you have a vector, then that vector needs to be passed around to every function call, so it has to be accessed from the function object.
4:01:07
beach
In the past, I considered passing such literals in the closure vector, but that's even worse, because then they have to be passed to intermediate functions that don't use them.
4:02:12
beach
But then I decided for SICL that I would make literals have fixed addresses, so they could be loaded from the instruction stream using one or two native instructions.
4:04:01
beach
So right then I was thinking that with call-site optimization, the issue disappears, or rather, it is replaced by the need to patch native code to insert a different address for the trampoline snippet.
4:05:47
bike
in native clasp, the literals vector (which isn't an actual lisp vector) is stored close to the actual code, and then when the code grabs a literal it just loads it from an address relative to the instruction pointer
4:08:14
beach
A PC-relative load is probably as inexpensive as a constant load in modern processors.
4:10:43
beach
I suppose you could even have the literals move if you allow the garbage collector to access that part of the instruction space and modify it.
4:14:13
bike
yeah, and storing the literals and code together means they can be collected together easily, too. not that we do that in clasp yet