libera/#clasp - IRC Chatlog
Search
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
22:28:38
karlosz
Bike: yeah the key thing should be 1's complement instead of 2s complement and then itll work
22:35:01
karlosz
Bike: you're right for changing the frame-end thing. it used to be there but then it got killed when i got rid of the extra hair for enclose (the thing that segregated closed over variables from local ones in the environment)
22:37:26
karlosz
could some of the fixes be cherry picked onto main? its annoying to have two branches but it can be convenient to have the non clasp version for testing when e.g. the vm branch isn't building cleanly
22:38:23
karlosz
i think the lexical environment structure is more or less finalized in terms of what it'll look like now, so the C++ versions shouldn't be an isuse wrt duplication
22:38:47
Bike
Sure. I mean, I've still been using #+clasp, so i think the clasp branch should still run portably? i hope? it's just got a lot of #+ #- stuff
22:40:26
karlosz
if it runs portably anyway i don't think there's a reason to have two separate branches
22:43:24
yitzi
drmeister: to do the nightly for homebrew you start the Bump formula action. I just started it.
22:43:31
karlosz
(mostly i want to be sure we're looking at the same generated code if we're debugging something)
22:46:18
yitzi
If you guys leave the existing code with conditionals I can make two separate build paths in koga if you need it. That way with the same branch you could make different images in two different build directories.
23:00:25
karlosz
ah, nevermind, i see that there is actually a fair bit of difference between the compilers now
23:01:33
karlosz
Bike: i think keeping two branches is fine but the clasp branch doesn't work with #-clasp and we could just nuke it
23:06:54
yitzi
drmeister: What do you think about giving option to CL_DEFMETHOD to NOT always generate the class/method names? I've got four vector classes and they each have a "vref" function by intention. Having 4 additional symbols generated for every function is kind of irritating: real-single-vector/vref, real-double-vector/vref, complex-single-vector/vref, complex-double-vector/vref.
23:24:11
karlosz
ive gotten it to work a couple times but i just got the error "boehmprecise/" is not a LIST
23:30:49
karlosz
yitzi: when i try to rerun koga i always get some error with a stale git lock file being present
23:38:14
yitzi
Please paste the error the next time you see it and I'll try to fix it. You can also do `./koga --skip-sync` if you want avoid the git pulls
23:39:15
yitzi
If that doesn't work use `./koga --deep-clean` ... that should avoid you having to reclone.
23:42:12
yitzi
btw, generally you should only have to rerun koga if there are new or deleted files in the build. A lot of the time you don't need to rerun that for small changes. koga = configure and ninja = make in terms of functionality.
0:18:20
drmeister
We could compile things as bytecode and then recompile them automatically as native code if we spend a lot of time in them - could we not?
0:52:51
drmeister
::notify yitzi delta-vega uses shasht:with-json-key and that's not external in shasht.
0:54:58
Colleen
yitzi: drmeister said 2 minutes, 7 seconds ago: delta-vega uses shasht:with-json-key and that's not external in shasht.
1:30:07
karlosz
drmeister: didn't have much time today to do much. trying to get caught up with Bike's C++ification of some of the code and then look at how to improve the actual C++ VM (i.e. where some indirections could be removed from accessing literal vectors)