libera/#clasp - IRC Chatlog
Search
13:44:09
drmeister
I've been thinking about this for a while - should we move to Discord - or is that a terrible idea?
13:46:36
Bike
discord has some nice features, but you have to sign up in a way you don't for irc, and it's run by a company rather than a nonprofit. also i don't think we actually need multiple channels
13:46:42
drmeister
I need to travel to ThirdLaw today, where my x86 MacBook Pro is (athena) and then I'll disable the something-something-security-system-protection mac thing so I can do proper profiling on it.
13:46:55
Bike
maybe if we get more users, if you're expecting a major influx of people who aren't familiar with irc
14:14:09
drmeister
Is the lexical valu/closure optimization pass being written as part of the compiler? It looks like it from the source code.
14:37:52
drmeister
I mean - I was just looking for confirmation that it was being implemented as a pass of the compiler. I see the `fixup` class and and `link-function`. Are those part of the lexical variable/closure variable optimization?
14:43:31
Bike
We compile the code by generating bytecode for each function in a module, with placeholder labels instead of actual labels. Linking puts all the function bytecodes in the same module, and resolves all links into actual offsets
14:43:57
Bike
The "fixups" are needed because labels can be variable length (like you can have 1-byte labels, 2-byte labels, or 3-byte labels) which means some adjustments need to be made for that
14:44:16
drmeister
Ah - I was looking for something that replaced MAKE-CELL with NOPs and then closed holes - or something like that.
15:44:20
Bike
i just noticed something i don't understand with the bytecode. if i check the bytecode-module/bytecode of some code, it looks too junky to run, even though it does run
15:44:41
Bike
starts with the sequence 29 1 15, which should be PUSH-VALUES CONST 15 and thus crash if there are not that many constants
16:02:53
karlosz
i think what i'll do next is try to iron out the fixup and label stuff even more by adding the cell optimization
16:03:51
Bike
exit is supposed to return values similar to how return does right? like if there's nothing on the stack leave the mv register alone, otherwise fill it up from the stack frame?
16:06:08
Bike
i thought the pop instruction was for facilitating this. well, ok, so how does it work then? in vm.lisp it looks like it's just passing up a single value?
16:07:03
karlosz
and in vm.lisp the function call to VM returning has nothing to do with the value passing semantics
16:08:32
karlosz
so if you did (return-from (f)) it just works, because (f) puts its values in MV and then exit just does the control transfer and the stack actions
16:08:57
karlosz
we needed pop because if you did (return-from x) then we'd have no idea how many stack frame slots to pop
16:09:38
karlosz
so for RETURN its the same thing: we can get rid of the gather logic there so its faster
16:11:21
karlosz
also, i think the branch instructions need to be updated for label offset being pointed at the start of the instruction?
16:12:49
karlosz
also sorry that i haven't been updating the c++ vm along with changes to the cvm, i just figured we might reduce any potential merge conflict this way
18:35:39
drmeister
I have an x86 Macbook Pro on the thirdlaw VPN that can do profiling. I could profile the bytecode interpreter once it works with cvm.
18:48:08
yitzi
I think that removing application.config and project_headers.h has made it easier to add an extension that doesn't use clbind. I tried to make a non-clbind version of lila before and I was getting all kinds of weird syntax errors when it tried to compile anything that used project_headers.h. With this method it likes it was pretty easy and no errors yet.
18:49:20
drmeister
Bike, karlosz: If you do get cvm compatible with the bytecode interpreter at the end of the day - tell me and I'll do some profiling.
18:50:17
drmeister
I could sort them based on inheritance. We don't use multiple inheritance so it should be a simple matter of sorting the headers based on the precedence of classes
18:50:54
yitzi
It could be. I don't really know for sure since I was not able to fix the problem. I was getting all kinds of weird errors from templates. This new method seems to work out of the box.
18:53:10
yitzi
I am letting it run the workflow tests. Everything seems to work but just making sure. I have already tested with boehm and boehmprecise. I am gonna run the static analyzer at some point just to be extra sure that I haven't broken anything.
19:37:26
drmeister
(setf (fdefinition 'fib) (compile-to-vm::bcompile '(lambda (n) (if (eql n 1) 0 (if (eql n 2) 1 (+ (fib (- n 1)) (fib (- n 2))))))))
19:44:00
Bike
also, sidenote, since you made entry points funcallable, you can actually just use compile-to-vm::compile
19:50:46
yitzi
drmeister: I'm note sure I understand the advantage of the class/name pattern from CL_LISPIFY for CL_DEFMETHOD. Doesn't that defeat the point of the specialization?
19:54:44
drmeister
yitzi: atom and residue inherit from matter. (matter/add-matter a-residue an-atom) works.
19:55:26
yitzi
Well, if I have class A and class B both of which have CL_DEFMETHOD A::fu() and CL_DEFMETHOD B::fu() ....
19:56:21
yitzi
Then I want (fu x) to call the right one. I don't understand what a single dispatch A/fu and B/fu help there.
19:56:23
drmeister
I'm thinking of C++ exposed classes as working more like Common Lisp structs than classes.
19:57:55
drmeister
After all this I think it's more valuable to have A/fu and B/fu to make it easier to discover what methods apply to instances of A and B than to be able to write (fu x).
20:01:31
drmeister
Yeah, but listing applicable methods based on specializers isn't useful to programmers.
20:02:40
drmeister
I was looking for something to help me find what methods apply to a particular class with name completion. Where I can type atom/<tab> and get all the atom methods.
20:06:27
drmeister
There are 105 of them that are hard to rename because the same method name is used by multiple classes.
20:11:54
karlosz
OK, here are the easy VM optimizations to make: Not using AREF for the literals vector, and using casting instead of manual arithmetic for reading labels
20:13:05
karlosz
does that use the same mechanism as cclasp in terms fo handling C++ unwinding and longjmp stuff?
20:18:17
Bike
oh yeah, related. when we exit out of a nonlocal block does that hit the entry-close? i think it ought to, maybe?
20:18:37
Bike
since blocks and tagbodies aren't distinguished in the ir, we can't exit the entry as soon as we do an exit
20:19:52
karlosz
like https://github.com/clasp-developers/cvm/blob/a4bc08d869fc0b321c4aeefd46d7ca913d794ffd/compile.lisp#L868
20:20:44
Bike
so we do hit the entry-close? like we hit the exit instruction, and then the next instruction is entry-close.
20:20:46
karlosz
for tagbody https://github.com/clasp-developers/cvm/blob/a4bc08d869fc0b321c4aeefd46d7ca913d794ffd/compile.lisp#L839 you jump to whereever the go tag is which doesn't have to
20:21:09
karlosz
Bike: yes for block return-from, the exit goes to the label right before the entry-close
20:21:31
Bike
and then in tagbody it won't in general, unelss the tag happens to be right at the end of the tagbody
20:22:11
karlosz
i think this is how i wanted it to work for cclasp as well but i think the reason we didn't do it is that llvm can't really express inter-function control transfer
20:22:57
Bike
Yeah, in llvm the block pretty much needs to control where you go next. we can't encode the destination at the return-from/go/whatever like we can in the vm
20:23:48
Bike
llvm nlx is entirely based on c++ exceptions, which suck, and are also very dynamic, so encoding a destination in the jump doesn't make sense
20:25:36
Bike
anyway, i think that's all the instructions implemented except catch, throw, catch-close, progv, long
20:25:52
Bike
so if we do like aclasp and compile catch/throw/progv as thunks, that should about cover everything
20:26:28
Bike
and then we can start trying it on clasp and watch it all burn as the edge cases i haven't thought of come up
20:30:50
Bike
i have not been thinking too hard about it, since aclasp already uses thunks for all of these
20:37:34
Bike
i don't know if that's the problem, but i imagine a million lines of output doesn't help
20:39:48
Bike
the vm might not react well to interruption. the NLX will react appropriately to exits but normal use might not
20:40:45
Bike
i suppose i can make bytecode_call pop the frame in a catch (...) instead of only doing it on nlx or normal return. that should make it work better with exits, i think
20:41:19
Bike
(i moved the bulk of the vm interpreter to another function bytecode_vm, to do the recursive calls thing for nlx)