libera/#clasp - IRC Chatlog
Search
23:53:02
karlosz
loading the bytecode compiler with the evaluator => Time real(1.145 secs) run(1.145 secs) consed(599904128 bytes) interps(83538) unwinds(274)
23:53:57
karlosz
compiling the bytecode compiler with the interpreted compiler Time real(92.837 secs) run(92.837 secs) consed(48175047168 bytes) interps(6751985) unwinds(12716)
23:56:49
karlosz
loading/compiling the bytecode compiler with the bytecode compiled compiler => Time real(59.228 secs) run(59.228 secs) consed(32253673960 bytes) interps(4356478) unwinds(12625)
0:12:20
drmeister
It contains loader.lisp and a `run` script to load the bytecode compiler, compile it and then continue trying to load bclasp.
0:13:57
drmeister
To get backtraces to work for bytecode I use the same trick I used for the interpreter. I compile a small llvm function at startup that installs a trampoline for bytecode functions. It spills the arguments to the stack and there is a stackmap entry for the trampoline.
0:16:33
drmeister
Bike, karlosz - After loading the aclasp code I remove the :clasp-min feature and then load the bclasp code. We can't use direct-calls.lisp or cl-wrappers.lisp until cclasp.
0:57:50
drmeister
karlosz: I see you just made a pull request. It makes a lot of changes to the C++ code as well. Is that intentional?
1:02:04
karlosz
drmeister: can you change this line https://github.com/clasp-developers/clasp/blob/1e8e3b1edf57c94580b3e7e813a942269ed08d47/src/lisp/kernel/cmp/bytecode-compile.lisp#L798
1:14:50
drmeister
I don't want to hold you here all night ... but we are making progress and I will keep going as long as it takes.
1:29:40
karlosz
i thought i could just wrap BLOCK around the lambda body, but that makes declarations not work...
1:31:26
drmeister
https://github.com/clasp-developers/clasp/blob/vm/src/lisp/kernel/lsp/evalmacros.lisp#L119
2:34:21
drmeister
So, safe-canonical-type is disturbingly close to where the load-time-value value was. Are you sure what I added is correct?
2:35:15
Bike
it should be. how is compile-load-time-value called? does it account for the read-only-p argument (by ignoring it)?
2:37:01
Bike
ok yeah i see, the bytecode compiler generates catch instructions (also throw, progv) which i didn't implement
2:37:42
Bike
replacing compile-catch with uh, (compile-form `(core:catch-function ...) ...) should do it?
2:38:26
Bike
I did not bother about implementing these yet because I figured we'd have enough bugs with the instructions we have so far
2:41:09
drmeister
Are you interested/available to implement these or should I quit for the time being?
2:41:56
drmeister
there's a 'loader.lisp' file with all these load commands and a `run` script that runs everything
3:01:13
drmeister
CMPINTRINSICS.LISP is the next problem. I'll investigate and if I can't fix it I'll stop for the night.
3:17:56
Bike
oh, symbol macros aren't fine, actually. compile-symbol doesn't know about global symbol macros
3:19:14
Bike
the var-info function should have a clause like ((ext:symbol-macro symbol) (values :symbol-macro (ext:symbol-macro symbol))) i think
3:35:12
drmeister
TYPE-ERROR (KEYWORD::DATUM 256 KEYWORD::EXPECTED-TYPE (COMMON-LISP::INTEGER 0 255 )
3:55:35
karlosz
yeah its specifically happening because the bytecode compiler can't yet compile more than 256 distinct literals in a function
4:32:10
karlosz
are we sure that everything is getting bytecode compiled? i see a lot of interps happening when i do time
5:51:57
karlosz
Bike: i made some nlx changes to the vm. i think GO was leaking stack by not reloading the Vm state on unwind so i fixed that. basically it looks like what the lisp vm does now
7:35:22
karlosz
drmeister: i tried making it so that referencing the literal vector in C++ doesn't go through aref. it seems to build and everything fine but then when i run it i get some bizarro error about not enough arguments somehow... i'm worried i just did something dumb and messed up some smart pointer or raw pointer rleated array coercion thing
7:35:26
karlosz
what i have is here: https://github.com/karlosz/clasp/commit/717957d03e5ec8ee08a603d184cc43e044866d36