freenode/#clim - IRC Chatlog
Search
10:30:09
jackdaniel
beach: what you might find interesting ECL compiler c1forms resemble very closely concrete syntax tree as described in cleavir document (they serve more purposses additionaly though)
13:27:52
beach
jackdaniel: I see what you mean. Though c1forms seem to be created by the compiler as opposed to being consumed by it.
13:30:47
jackdaniel
beach: yes, in cleavir/eclector things are finely separted, in ecl many things are interwinded
13:31:57
jackdaniel
c1form also serves a purpose of ast and ir (and representation is pretty simplistic)
13:33:29
jackdaniel
I've mentioned that I'm making a document for better ecl compiler comprehension, here is its current state: https://gist.github.com/dkochmanski/fc361643488c8059a6030f143ac94a6d
13:34:47
beach
Great! Is it just for your personal consumption, or do you expect others to read it as well?
13:35:15
jackdaniel
for now it is a sketch for myself, I plan to write something better organized later
13:35:42
jackdaniel
if you have some remarks regarding content I'm happy to hear them, but I'm not interested in typos (I'd run flyspell first if I were)
13:36:44
jackdaniel
there are more to come, I didn't explain i.e environments, but I've already learned a lot while writing it
13:37:28
beach
Yes, I can see how attempting to write such a document would force you to understand things in detail.
13:38:18
beach
It is interesting to see how people write Common Lisp compilers when they don't have standard classes nor generic functions.
13:39:10
jackdaniel
dispatch tables are a clever substitute. I think that I'd find it much harder to follow the code if there were auxiliary methods for generic functions
13:40:07
jackdaniel
they are easy to write but I find them hard to read when trying to comprehand the full behavior
13:40:12
beach
Wouldn't the dispatch table just be primary methods with an EQL specializer the way we do in Cleavir?
13:40:59
jackdaniel
yes, they would. and ecl could use clos to its full extent, because it is compiled with full cl available
13:41:57
jackdaniel
bytecodes compiler and interpreter are C programs and they are used to first load Common Lisp, and then the compiler
13:43:41
jackdaniel
function eval is implemented in C (there is a single one). there are two compilers and a common runtime
13:46:48
jackdaniel
when you funcall the function, then it is checked if it is bytecodes function, bytecodes closure, c function etc, and if it is a function in C, you call it object->pointer(), if it is bytecodes function then ecl_interpret(frame, env, function) is called
13:48:10
jackdaniel
(maybe ecl_interpret is what you consider a second evaluator, then there are two indeed)
13:49:43
jackdaniel
when you call ecl_funciton_dispatch then yes, but compiler is often smarter and inlines the call if it is known
13:50:56
jackdaniel
you may want to see file src/c/eval.d (ecl-apply_from_stack_frame and ecl_function_dispatch)
13:51:12
beach
One trick to avoid the check is to make interpreted functions be a compiled wrapper that calls the interpreter.
13:51:46
jackdaniel
yes, but bytecodes compiler is designed to work even if there is no C compiler on the machine
13:52:59
jackdaniel
I guess that could be solved with a general-purpose closure generator compiled beforehand, but I'm not sure if that won't defeat a gain, I will think about it
13:55:23
jackdaniel
either way "ordinary" function dispatch doesn't seem to be a bottlneck in ECL performance, dispatching generic functions is dreadful otoh and that's what I will focus on first when improving these things
14:02:00
beach
One amusing idea I had was to figure out the general format of a C file generated by the compiler, and write a Cleavir backend that generates such files.
14:07:24
jackdaniel
that's what I meant when I've suggested that we could try use Cleavir as an alternative compiler -- to make it target ECL's runtime
14:10:28
jackdaniel
it might require some tricks. i.e (as things are currently done) top-level forms are "replayed"
14:10:57
jackdaniel
also, closures compiled for C code are implemented by passing to them their environment as an argument
14:14:23
jackdaniel
in <file-name>.c there is an init_fas_CODE function, it installs the functions one by one, defines classes etc based on things stored in a VV vector (data segment)
14:14:56
jackdaniel
that's another big bottleneck in ECL, when you have big system which is compiled to the executable initializing it takes a lot of time
14:16:23
beach
Perhaps the code for doing it could be made faster, but I don't see how you can avoid the actions.
14:18:04
jackdaniel
I don't know a way either, but that's certainly something what needs to be addressed at some point of time (i.e by writing faster code)
14:19:05
jackdaniel
maybe intead of replaying top-level forms by executing each form sequentially maybe one could just "apply the difference" to the internal ecl runtime tables
14:20:26
jackdaniel
that would be certainly useful for save-lisp-and-die on ecl (which doesn't exist so far)
14:21:45
jackdaniel
me neither; maybe the only way forward is to make replaying faster but using internal functions