libera/#clasp - IRC Chatlog
Search
18:15:35
Bike
okay, i manually went through to try to figure out the stack position after each instruction (which capability i should add to the tracer, by the way) and i think the bytecode as written is trying to draw elements past the bottom of the stack frame for the function
19:30:26
karlosz
Bike: i though about sp being statically determinable and i don't think its true (because of multiple values)
19:32:37
karlosz
if we had ENTRY-BIND <frame-slot> and RESET-STACK-POINTER <frame-slot> that would make local unwinding fast
19:38:01
Bike
karlosz: when we hit an entry-close, the stack pointer should go back to where it was just before the corresponding entry, right?
19:39:03
karlosz
i think i debugged this quite thoroughly for the lisp vm if you want a more precise reference
19:39:43
Bike
I have some bytecode here that does ENTRY-CLOSE REF 7 ENTRY-CLOSE. would the compiler ever generate that? i mean, the ref'd data will be dropped, right?
19:49:53
Bike
i think this bytecode (not that part in particular) might be getting generated wrong, but i am not sure
19:50:11
Bike
it's also a bit hard to test on sbcl because all the macros would have to be expanded by hand, maybe
19:52:54
Bike
the runtime problem, at least, is definitely that it's doing a CALL 3 when there are only three things on the stack
20:09:13
Bike
http://ix.io/47YR here's what i'm compiling and the bytecode, with little annotations as i try to work out the stack positions
20:09:34
Bike
so i'm pretty sure the bytecode is in fact wrong, since the append call is missing the middle argument entirely
20:26:52
Bike
if i'm reading the disassembly correctly, the value of (let ((forms ...)) ...) ought to be pushed to the stack in %2, before the first FDEFINITION 4
20:27:06
karlosz
you can have all the functions in the module get dumped out by just scanning for bytecode template objects in the letrals vector
20:27:31
Bike
and i think ref 5 is supposed to be that, maybe? but it's before the entry-close instead of after
20:28:31
Bike
and that's how it would generate, since that entry-close is for the implicit block nil of the do
20:31:46
Bike
(bytecompile '(lambda (f) (list (block nil f)))) has the same problem. now that's something i ought to be able to compile in sbcl
20:34:59
karlosz
Bike: (compile-to-vm::compile '(LAMBDA () (print (BLOCK NIL (RETURN-FROM NIL))))) fails
20:43:35
karlosz
probably we should've just tested if the non-pidgen compiler could compile and run itself
20:44:27
Bike
okay, so compile-return from already compiles its form in a receiving-t context. so now we just need to have compile-block generate a push if it's in a receive-1 context
20:44:35
karlosz
i'll add the push instruction to the main cvm branch and try to see if it can self host.
20:51:05
Bike
i don't know what the sbcl vm is doing, but the disassembly is FDEFINITION 0 ENTRY ... REF 0 ENTRY-CLOSE CALL 1
20:52:17
karlosz
https://github.com/clasp-developers/clasp/wiki/Virtual-machine-design#nlx-instructions
20:52:39
karlosz
Pop a block dynamic environment from the dynamic environment stack (not the VM stack), marking it as invalid.
20:53:07
Bike
i asked "when we hit an entry-close, the stack pointer should go back to where it was just before the corresponding entry" and you said it should go to the sp saved on the corresponding entry
20:53:58
karlosz
we just unconditionally compile the block in an mv context and have entry-close also do unwinding?
20:59:51
karlosz
but for now maybe just pushing and having entry-close muck with the vm stack pointer will work.
21:00:37
Bike
i think it will work. i see what you mean about entry-close not needing to reset the stack though.
21:01:32
Bike
practically speaking, i don't think clasp could implement an exit-single that would be more efficient (i.e. that would not just use the mv anyway) without a total overhaul of its nlx, but it does make sense conceptually i think
21:09:49
karlosz
Bike: i have a compilation strategy that doesn't rely on entry-close also muning with the stack pointer
21:10:29
karlosz
for the case where block is in a 1 value receiving context (like in the above) we make the normal control flow do its usual thing
23:13:14
drmeister
What's the current problem? macrolet? The discussion above looks to be about an optimization.
1:14:37
drmeister
Communication from Lang Hames. I have three issues with LLVM and it looks like it will be a while until they are fixed.
1:14:59
drmeister
Now that I think about it - the bytecode compiler/interpreter will help us with all of these.
1:15:41
drmeister
If we shift code to bytecode compilation then there will be less DWARF code to finalize - so shutdown will be faster.
1:17:28
Bike
the current problem is the bytecode compiler not handling certain nonlocal exits correctly