libera/#clasp - IRC Chatlog
Search
17:04:07
Colleen
karlosz: Bike said 1 hour, 59 minutes ago: the push strategy seems to solve the nlx bug as expected. gonna go with that for now in clasp until we come up with something smarter
17:04:07
Colleen
karlosz: Bike said 1 hour, 58 minutes ago: for local-unwind we could have (LOCAL-ENTRY N) save sp to local N, and then (LOCAL-EXIT-8/16/24 N LABEL) load the sp and jump
17:05:24
karlosz
BIke: cool that push fixed it. i think its sort of unavoidable unless we change the mv strategy in general, although the compilation strategy in the main cvm branch is more efficient that the one in clasp right now in terms of bytecodes emitted and how much work entry-close needs to do
17:06:45
karlosz
Bike: is there not a smart way we could have LOCAL-ENTRY and ENTRY be the same thing? i'm asking because it would be nice if we could make the decision to have local exits be per exit and not per entry
17:13:44
Bike
that seems inevitable to me, since ENTRY means we have to do whatever setup for NLX to work properly, like setjmp
17:14:32
Bike
and setting up the unwind tables. both of which are what we want to avoid for the local case
17:22:31
Bike
we are doing setjmp and longjmp so we can unwind the frames of any intervening c++ frames, yeah
17:23:29
karlosz
instead of a local exit instruction its probably more convenient to just have a LOCAL-UNWIND <n> instruction and then JUMP
17:24:41
karlosz
whereas NLX sort of needs to have its own control flow instruction because vm implementations may do something more convoluted with the PC
17:46:42
drmeister
Bike: How about running ansi tests with the bytecode compiler running in the interpreter - or the bytecode compiler running after compiling it with aclasp?
17:57:52
Bike
actually i just take my example here and rename it so it doesn't redefine part of the compiler
18:05:55
Bike
ok, it looks kind of like the cell elision is being applied incompletely to rest parameters
18:13:54
Bike
(funcall (funcall (bytecompile '(lambda (a) (setq a nil) (lambda () a))) 7)) => 7 instead of nil, too
18:15:25
Bike
drmeister: does "CONS_CAR(a_t_sp) = another_t_sp" do rplaca? should i be doing something else?
18:21:36
drmeister
Use this: https://github.com/clasp-developers/clasp/blob/main/include/clasp/core/cons.h#L207
18:31:37
drmeister
If you don't then if (a_T_sp.consp()) { gc::As_unsafe<Cons_sp>(a_T_sp)->rplaca(val); }
18:32:11
drmeister
Or gc::As<Cons_sp>(a_T_sp)->rplaca(val); and be aware that that does the consp test
19:20:49
karlosz
also (funcall (funcall (bytecompile '(lambda (a) (setq a nil) (lambda () a))) 7)) => NIL with the Lisp vm
19:22:04
Bike
by binding in reverse i mean that ((lambda (&key a b c) ...) :a 7 :b 5 :c 8) will bind a b c as 8 5 7
19:24:20
Bike
yeah, if i have compile-lambda-list reverse the key names it works. so i think this was a victim of the pidgin
19:25:26
Bike
it doesn't, but i see now. you did (mapcar #'caar keys), but i had to change that to a do because of process-lambda-list's obnoxious format
19:25:59
karlosz
can we not just make process lambda list do what alexandria:parse-ordinary-lambda-list does?
19:26:34
Bike
if the bytecode compiler lets us rip out the c++ interpreter, we should be in a better position to make that kind of improvement
19:28:09
Bike
but the error is "unknown opcode 150", so something is jumping around improperly i guess
19:37:06
Bike
i have it hooked up to do that in the clasp branch, or you can get the bytecode with (core:bytecode-module/bytecode (core:global-entry-point-code gep-here))
19:41:37
karlosz
Bike: for (bytecompile'(lambda (a) (setq a nil) (lambda () a))) i'm pretty sure CELL-SET is not doing the right thing
19:45:15
Bike
this function actually does have a 150 opcode in it, right after the mv-call-receive-fixed 20
19:46:49
Bike
yeah, some kind of miscompiling... it's trying to compile comple-function and this happens
19:51:54
karlosz
i fixed this thing i mean: (funcall (funcall (bytecompile '(lambda (a) (print a) (setq a nil) (print a) (lambda () a))) 7))
19:52:17
karlosz
its this https://paste.gnome.org/IpsN6jDgZ as drmeister suggested. i just verified it works
19:58:47
Bike
i'm not surprised that eliminating an if fixes the problem, but am kind of surprised that replacing one of the let* values with nil does
20:22:58
drmeister
Can the disassemble code do some sanity checking - that the jumps are reaching the labels?
20:37:49
Bike
the fixup code in the compiler, that takes care of things like resolving labels to relative jumps of the correct length and deleting unneeded cell instructions, is apparently putting a jump offset in the wrong place, so it ends up looking like an opcode
21:29:19
karlosz
we're just missing an argument here (phew!) https://github.com/clasp-developers/cvm/blob/64bb11bd8928606c6bef9e4cfbaba25f48910556/compile.lisp#L947
21:31:43
karlosz
yeah, i souped up the disassembly a bit to verify that the fixup stuff wasn't the culprit
21:32:28
karlosz
i am still pushing the stuff to the main cvm branch... i hope that's clearer than dealing with the two pidgin and non pidgin clasp versions....
21:56:44
Bike
`clasp -I -f clasp-min --norc -l 'loader.lisp'` where loader.lisp is https://www.irccloud.com/pastebin/K09NVmoW/ with the lines uncommented
22:56:40
karlosz
i get ;; -read- for al the forms in init and then it just doens't seem to do anything for a while until it sudenly prints loaded everything
23:16:56
drmeister
I think I want to move bytecode-compile.lisp to after cmprepl.lisp so that it gets compiled to native code.
23:17:27
yitzi
You should be able to use the sys logical host versus in loader.lisp, i.e. "sys:src;lisp;kernel;tag;start.lisp"
23:31:22
drmeister
jeeeze loueze - aclasp compiled bytecode compiler doesn't run faster than when it's interpreted.
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