libera/#clasp - IRC Chatlog
Search
19:08:55
Bike
I'd also like to set up clasp-developers.github.io with similarly auto generated documentation, but when i tried that last week i managed to screw up the formatting something fierce
19:22:30
Bike
I tried putting in the documentation generation for cleavir but it failed for a silly reason I'm fixing now
22:55:40
drmeister
https://github.com/clasp-developers/clasp/blob/main/src/lisp/kernel/cleavir/translate.lisp#L2018
22:56:23
drmeister
It appears to take constants from a (BIR?) module and generate load-time-values for it when cst-to-ast:*compiler* is 'cl:compile-file.
22:58:12
drmeister
Could the bytecode compiler be adapted to do something like this? Accumulate constants as it compiles and then generate load-time-values for them? I presume this uses the LITERAL compiler.
23:02:37
drmeister
If we did something similar for bytecode and we have Cfunction_O::link_function invoke the literal compiler to generate function descriptions and simple-fun's and return the BytecodeModule_sp object then we can add the bytecode_module and the startup bytecode generated by the literal compiler to FASO files and we would have compile-file be able to generate bytecode.
23:03:41
drmeister
Then we add source file info to this somehow and we could take the next step and convert bytecode+source file info into Cleavir-IR.
23:04:47
drmeister
compile-file to bytecode followed by judicious compilation to native code of oft called functions is the goal.
23:18:42
Bike
I am on variably. And yeah that's what that function does, with a BIR module. What you're describing is along the lines of what I've been imagining
23:19:12
Bike
The bytecode modules already kind of do constants in this way, but we'd have to add some stuff for load-time-value, and for generating the faso machin code of course
23:20:53
Bike
What I've been figuring is that for compile file we would make a bytecode compiler module, and then keep adding functions into it, and then at the end we have a bunch of bytecode cfunctions, a vector of constants to generate code for, and probably a vector of load-time-value forms or functions or something. then we fasoify it during linking.
23:21:11
Bike
the linking process would be a little different, since at compile time we wouldn't actually need to make bytecode entry points (though we could if we wanted)
23:42:52
Bike
for load-time-value, we'd probably have a bytecode function for each one, to compute the initial value, so we'll have to arrange something in FASOs to call bytecode functions for that (as opposed to native, which we do now)
0:58:48
anker
I'm new to all of this, tasked with generating builds from AST with clasp. I'm trying to find docs on the packages/API in clasp (esp. CLANG-AST, C, CLANG-TOOL, etc.) and demo code to get started, introduce myself and hopefully get some help!
1:14:39
Bike
anker: our documentation is at https://clasp-developers.github.io/. I don't think we have documented the clang AST matchers/libtooling stuff, which we don't load for normal use
5:13:16
nij-
I've just watched this nice talk again https://www.youtube.com/watch?v=8X69_42Mj-g Got a bit confused.. seems that the goal is to use C++ libs easily in CL. But why go all over the ways? Can't we just use CFFI to glue CL and C++ with C?
5:30:33
drmeister
whereiseveryone: yes - we just added the feature to start/run/shutdown clasp as a library
5:35:48
drmeister
We haven’t set up clasp to build as a library yet. That would require a bit of work with the build system.