libera/#clasp - IRC Chatlog
Search
16:25:04
Bike
so i guess i should get started on the bytecode interpreter by writing it in bytecode_call, right
16:25:18
Bike
and the vm bytecodes had defines somewhere... or if not i can do it, there's only like twenty anyway
16:37:09
drmeister
yitzi: You changed everything on the www.thirdlaw.tech so that it is owned by the user 'www'. How do I edit the web page in index.html?
16:37:37
drmeister
I've tried becoming the user 'www' but that doesn't appear to be a fully enabled account.
17:17:05
Bike
drmeister: so how would i go about making a callable bytecode function? I see bytecode-module/make, and bytecode-closure/make, but the latter requires an entry point? which i guess i also make?
17:47:52
drmeister
yitzi: I was able to edit the index.html file. cracauer had it under revision control using rcs. I think I broke that.
17:48:23
drmeister
bytecode-closures are already callable. They end up in the C++ function `bytecode_call` in functor.cc
17:49:36
Bike
i want to manually construct a bytecode vector and then call it to see if the C++ vm works
18:19:11
karlosz
in particular relative offsets tend to be smaller than absolute (e.g. module start) offsets
18:23:00
karlosz
i think i made the special bindings machinery more optimal. i don't think i bungled scoping but there's a possibility? also let* and &aux work now
18:28:06
Bike
i think the compiler's at the point where we can just make it clasp specific from here, and that'll be easier than doing all the crap with declarations that needs to be done
18:29:27
karlosz
cool, let me know if the specification is wonky anywhere else. the lambda list stuff may be a bit confusing
19:46:58
Bike
drmeister: the vm branch is fully merged, right? can i delete it? (i want to make my own vm branch and don't want a collision)
20:49:42
yitzi
We've some stale branches around. https://github.com/clasp-developers/clasp/branches/stale
20:50:24
yitzi
The old master could be deleted, obviously. Along with with any that have zero additional commits. Presumably they were merged.
23:49:04
karlosz
im having a hard time designing catch to work properly. that might be one of those things that can't be represented very well in the Lisp prototype
23:49:34
karlosz
in particular im having a hard time separating the semantics of closing the catch (pop dynenv) from the semantics of throwing up to the tag
0:01:52
drmeister
Bike: I pushed changes to cvm/compile.lisp so you can generate a header file with VM instructions.
0:09:22
drmeister
You may need to add more depending on what characters you put into the vm symbols.
0:15:55
drmeister
::notify Bike the arguments for jump dereference *pc as an unsigned byte - so we can only jump forward and by 256 bytes. We need to implement the clisp argument compression scheme that can handle signed 7bit, 15bit and 32bit values.
0:19:31
karlosz
stassats: its not for the vm. i thought about emulating catch and throw with lexical exits like in sbcl, but it's not a good fit for what we're trying to do
0:23:01
karlosz
::notify Bike I implemented catch and throw pretty much the way clisp does by saving the label in the dynenv object, should work with the clasp representation i think. in the prototype vm it seems to work with interleaving native and bytecode
0:23:53
karlosz
stassats: that's just what non-local exits are supposed to do. the question is what's the best design for bytecode instructions to encode that
0:25:35
karlosz
we want something that is high level enough to be easy to compile to. its a stack machine, so no registers
0:25:53
karlosz
a primitive set of orthogonal bytecode instructions that are compact and fast to interpret
0:26:13
karlosz
the design is here if you want to read it: https://github.com/clasp-developers/clasp/wiki/Virtual-machine-design
0:27:15
karlosz
so, for example, when implementing multiple values, there are no temporary registers you can use to save the start of any values globs. you have to find some clever way to deal with multiple value call, for example by keep the stack top as n-vals, vals*
0:28:10
karlosz
and we also want the bytecode instruction set to be easy to compile to in one pass. no register allocation, no environment analysis, etc. it's supposed to be a drop in replacement for the interpreter. as you can see, a lot of different constraints to keep in mind
0:29:11
stassats
i can make a quick catch like this: https://gist.github.com/stassats/136adc22bfea0f703a4abebb37bf8066
0:33:57
karlosz
stassats: yeah, like i said, i briefly thought about using lexical exits to emulate catch, and i think clasp does do that, but its not really a very fast or compact way of doing it
0:37:26
karlosz
so dedicating 3 to do catch, throw, and catch close is not a bad idea. we also need the primitives to produce clasp specific dynamic environments
0:39:07
karlosz
drmeister: we'll need to add it soon once we have larger functions definitely. i think on the compiler side the assemble function needs to change to support it. labels will also need to conservatively use the maximum size
0:41:23
drmeister
We can write the functions to compress and decompress in C++ and expose the compress functions to Common Lisp.
0:46:10
karlosz
drmeister: we have the same kind of instruction format clisp does. operands and labels, which both need compression and decompression
0:47:21
karlosz
stassats: you want to be able to inspect the current catchers on the stack? i don't understand why it should be special. there could just be a function to grovel the on stack catchers if there isnt already
0:53:30
stassats
a special variable will make establish catch slightly more expensive, but unwinding that doesn't involve catch would be faster
1:07:55
stassats
but the speed up for unwinding would be less than the slow down for catch, and it will increase the pressure on the binding stack