libera/#clasp - IRC Chatlog
Search
11:01:56
yitzi
My changes to project_headers has broken the nightly builds b.c. those use absolute paths during building. Working on a fix.
11:41:26
yitzi
The normal build and analyzer should be fine. It is when one does a "reproducible build" in which koga replaces the build path names with the destination installed pathnames.
13:02:41
Bike
i'll want to improve the vm disassembler before doing that, like making it print textually and doing labels
13:24:54
Bike
you'll have to do (vm::disassemble-bytecode (core:bytecode-module/bytecode (core:global-entry-point-code function-goes-here)))
13:34:29
Bike
ok, pushed to vm/main so that it will let vm:disassemble work on bytecode entry points, i think
14:38:22
drmeister
Good thing cell elision is working - and this is a reminder of how Common Lisp works.
14:40:36
Bike
we could soup up the compiler to do the very basic optimizations required to eliminate that, like reducing - to two-arg--
15:33:31
Bike
Yes, but given a bytecode module there's no way to get the entry points into it, I don't think
15:41:00
drmeister
Do you get the module and then disassemble that without considering the entry point?
15:41:41
Bike
Yes, and even if we were disassembling from an entry point, it would be nice to display all the entry points, so you could see where any local functions are etc
15:47:26
yitzi
drmeister: There is a docker build for clasp and one for cando-demos. They are weekly.
16:03:52
Bike
By the way, it looks like even in the existing interpreter, macrolet uses ext:parse-macro, which is written in lisp, to come up with macroexpanders. So if we want the bytecode compiler to be complete and in C++ we will have to rewrite parse-macro into C++
16:18:08
Colleen
karlosz: Bike said 15 hours, 13 minutes ago: the env structures replace the ones in compile.lisp. i pushed how it looks in the clasp branch of cvm (didn't want to make main even messier than it was)
16:18:08
Colleen
karlosz: Bike said 14 hours, 52 minutes ago: they were written in anticipation of the eventual port of the compiler to C++
16:21:27
drmeister
I moved the side stack to the top of the main stack. It's directly contained within the VirtualMachine class.
16:40:13
yitzi
We don't depend on specific version of fmt. But it may have been linked with v8 b.c. the build was older then the current version. The new build should use v9.
18:17:03
drmeister
If we do it after cmprepl it will be compiled by aclasp - it will be the only thing compiled by aclasp.
18:18:10
drmeister
For now we still have the aclasp compiler. Once we write a C++ compiler we can really rearrange things.
18:20:52
drmeister
We have to carefully take apart the aclasp code generator because we reused a lot of it.
18:21:32
drmeister
I mean - you can put it before cmprepl - then it will be interpreted using the C++ interpreter.
18:22:02
drmeister
We don't want to run it that way because that will be slow. So we could (1) compile it with aclasp (just for now) or (2) compile it with itself.
18:22:52
drmeister
For (1) load it before cmprepl and then change cmprepl to use it and then load it again so it compiles itself into bytecode
18:23:11
drmeister
for (2) load it after cmprepl and then replace aclasp compiler with the bytecode compiler.
18:24:10
drmeister
Then LOAD all of bclasp and cclasp cleavir code and then have cleavir compile-file everything.
18:26:47
drmeister
It's probably better then to put the bytecode compiler before cmprepl and change cmprepl to use the bytecode compiler.
18:28:29
Bike
Should be pretty full featured. There are some fiddly bits that are wrong, but I don't know if clasp relies on that much standard conformance
18:28:40
Bike
i'm rewriting the bytecode compiler a bit to use clasp's functions instead of alexandria now
18:33:15
drmeister
https://github.com/clasp-developers/clasp/blob/main/src/lisp/kernel/cmp/cmprepl.lisp#L75
18:33:23
karlosz
here is what i was thinking for bootstrap: we use the C++ interpreter to load the bytecode compiler, then self compile the bytecode compiler with the bytecode compiler
18:33:42
drmeister
And wherever you see bclasp-implicit-compile-repl-form change it to the new bytecode-implicit-compile-repl-form
18:34:36
karlosz
the bytecode compiler is still really small - so having a C++ interpreted version compile itself should be faster
18:34:52
drmeister
Then it will do what karlosz just said - minus the rip through aclasp bclasp etc. That we have to talk about next.
18:35:32
karlosz
unlike with the basic Lisp -> LLVM one pass translator which is a couple files and takes a while to compile itself with the C++ interpreter
18:36:45
drmeister
I think we rearrange cscript.lisp to repeat the aclasp files and add the bclasp files after that and once that's all loaded we will have a full bytecode Common Lisp.
18:53:52
drmeister
Oh - sorry - I thought it was done. I did notice that it seemed to upgrade very quickly and didn't download much if anything.
19:04:07
Bike
hang on, i think the allow other keys negation scheme won't work if there are no key parameters but there is &key
19:08:58
yitzi
So are we thinking that the it will be load the vm stuff then load cclasp sources, then parallel compile cclasp?
19:09:34
yitzi
Sorry that was a little garbled. 1) load a+bclasp stuff 2) load cclasp 3) compile cclasp
19:14:05
drmeister
So: 1) load aclasp 2) load bytecode-compiler 3) load byte-code-compiler 4) load aclasp+bclasp+cclasp 5) compile-file aclasp+bclasp+cclasp using cleavir.
19:16:23
drmeister
Bike: https://github.com/clasp-developers/clasp/blob/vm/src/lisp/kernel/lsp/evalmacros.lisp#L196
19:18:21
yitzi
Ok, I think I could probably make it switchable between vclasp = 1-4 and the usual steps. Let me know what and when I can help.
19:50:12
Bike
speaking of structs, should we work on runtime struct support next? like, packed structs rather than using instance
19:56:02
Bike
i guess the &key &aok thing could be fixed by saying aok is the high bit set, rather than using negation
19:57:11
Bike
the bytecode compiler also uses some seq functions that we have in seqlib, like replace
19:57:29
Bike
is that ok for doing things early? i mean, in C++ it would just be a std::copy or memmove or what have you
20:01:16
Bike
if you pull the latest compile.lisp from the clasp branch of cvm, i think it's pidgined enough (the header generation code will need to be commented out)
20:03:06
Bike
actually there's probably a bunch of places that need better declaration handling, so i'll just do that now
20:51:49
Bike
i don't understand why there doesn't seem to be anything in the code for resetting the frame-start to 0 in a nested function
21:21:17
Bike
i've been putting off fixing this because specials make lambda lists even messier than they already are