libera/#clasp - IRC Chatlog
Search
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
3:07:30
Colleen
Bike: drmeister said 2 hours, 51 minutes ago: 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.
3:07:30
Colleen
Bike: karlosz said 2 hours, 44 minutes ago: 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
3:07:50
Bike
i think i'm the best placed person to do the nlx stuff in the vm, since i've rewritten clasp's nlx like three times so far
3:08:51
Bike
this is what, some scheme like if the high bit of a byte is zero it's just a seven bit number, if it's one it's two bytes?
3:31:54
Bike
by the way, for the non-vm thing i was doing i ended up taking a look at all the bclasp special operators, and hoo boy. we might have to make some changes to the aclasp/bclasp sources to make them bytecompilable
3:34:39
Bike
oh, like just bytecompile everything from C++ and load cleavir from there without using the aclasp compiler?
3:35:30
Bike
right, well even then we'd have to watch out for stuff. e.g. in clos we use a couple special special operators for vaslists and stamps
3:35:55
Bike
in my other branch i've put in function calls for those, so they should be easier to work with
3:36:53
Bike
so either we need to build that special support into the bytecompiler as well, or do something less special
3:38:45
Bike
cclasp is now using them fairly extensively, but they should be basically untagged in that case, so they don't need any lisp accessibility
3:40:07
Bike
it uses "unboxed" vaslists. like how an unboxed double is just an llvm double, an unboxed vaslist is just { i64, i8** } or whatever it is
3:41:06
Bike
the idea is to let code like (lambda (&rest r) (dolist (x r) (print x))) not cons a rest list or even a tagged vaslist pointer
3:59:04
drmeister
It tests the uint16 argument functions by writing and reading powers of 2 and the int32 functions the same way for positive and negative numbers.