libera/#clasp - IRC Chatlog
Search
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