libera/#clasp - IRC Chatlog
Search
15:30:04
bike
i don't understand this special name thing, and me not understanding why there's a main dylib is part of that
16:29:13
bike
i mean, eventually we pretty much want to remove the native code compiler and always go through bytecode, but there are steps before we can do that
17:50:48
drmeister_
Other dylibs are created for sequential lists of faso's that were compiled at the same time as part of one compilation unit.
17:52:15
drmeister_
You know how you can combine fasos into a single faso? Clasp keeps track of sequences of faso's that were all compiled together. If I recall correctly when the faso loader recognizes that you are transitioning from one sequence of object files that were compiled together to another sequence, it creates a fresh dylib to link the new sequence of object files together.
17:53:28
drmeister_
One jitdylib per object file would not work, there would be too many of them. There are builds where we have more than 10,000 object files.
17:53:49
drmeister_
One single jitdylib for the entire system won't work because there would be name collisions (I think).
17:55:01
drmeister_
If I remember correctly, each object file needs a unique C extern symbol that we lookup to initiate linking. JITLink is triggered by looking up a symbol. It's fundamental to the design.
17:58:07
bike
okay, that makes sense. i guess it's just a matter of figuring out this weird name thing then.
17:58:29
bike
i'm also going to see if i can't do compile without a startup function. just looking up the XEP functions and the literals vector.
18:00:32
drmeister_
In order to get Orc to link an object file and generate relocated code you need to lookup the symbol "clasp_startup_0"
18:08:09
bike
next mystery is how gcrootsinmodule works. it would be convenient if the literals vector was just a C array but i guess that's not the case.
18:10:58
drmeister_
It maintains pointers into the lexical array, a vector of function pointers and a vector of transient/scratch values.
18:11:59
drmeister_
The virtual machine simply initializes values in the lexical vector, the transient/scratch vector and calls functions in the function pointer vector.
18:12:33
drmeister_
I think it's really good at it's job. I think we should keep it rather than use your much more general virtual machine.
18:14:16
drmeister_
Arguments for this "startup virtual machine" are compressed using a <number-of-bytes><vector-of-bytes> scheme.
18:15:49
drmeister_
Your bytecode machine is more general - you have conditionals and loops. The startup virtual machine doesn't have those, it just runs through the startup code from start to finish.
18:17:23
drmeister_
I'm talking about two virtual machines we have. How about the "startup virtual machine" and the "lisp virtual machine". They both use their own bytecode.
18:17:33
bike
we have three virtual machines. first there's the one that runs lisp bytecode - what cmp:bytecompile produces. then we have the faso virtual machine that constructs a faso literal vector. and finally we have the bytecode fasl virtual machine that constructs the fasl's literal vector.
18:18:19
bike
what i've been talking about is subsuming the second into the third, so we end up with two virtual machines - one that runs lisp code and one that builds up literals in a fasl.
18:22:35
bike
so, the gcrootsinmodule also contains state for the faso VM? is that just kept around after the faso is loaded?
18:39:44
drmeister_
I think the gcrootsinmodule must be kept around until all the faso initialization is done. Look at when the transient is wiped out. I think the gcrootsinmodule wouldn't be needed after that.
18:41:16
bike
well, it looks like literals access from cclasp code is just a t* array, so that's convenient enough