libera/#clasp - IRC Chatlog
Search
23:11:20
drmeister
The stack growing down is the convention that I'm used to. It made sense when we had a small amount of memory and you had the stack growing down and the heap growing up. But we have a fixed stack size now so it's not a problem if you want the stack to grow up.
23:15:45
Bike
which way the stack is laid out in memory shouldn't really affect the conceptual organization
23:16:37
karlosz
Bike: i finally settled on how to compile mv-call. i pushed it just now and also changed the vm design doc. it can handle arbitrary arg forms and i think it works quite well
23:17:02
Bike
i just realized i screwed up the dynamic variables, so i will fix that... at some point, dunno if you're still pushing things
23:17:44
drmeister
What about the left to right evaluation of lisp arguments? Isn't that easier with a bottom->top growth stack? Otherwise you subtract arguments number of words from SP and maybe use extra arguments to put evaluated arguments in the right place?
23:17:45
karlosz
but a bit more elegant because we have a stack machine. pretty much the idea is that we have a new APPEND-VALUES instruciton and we share the same machinery with MULTIPLE-VALUE-PROG1. i *think* it should interact well with unwinding
23:18:42
karlosz
Bike: not planning to push anything in the near future, you can fix that whenever or i will deal with whatever conflicts
23:19:24
karlosz
drmeister: the cvm code is compiling into a model of BytecodeModule_O modeled as a Lisp struct which was written before the clasp stuff was ready
23:31:43
Bike
(m-v-c a (b) (c)) is ...a... call b, push-values, call c, push-values, pop-values, mv-call
3:10:07
Bike
we could make symbol-value a little faster by computing an index at load time, and then skipping the get-an-index-if-there-isn't-one step
5:46:49
karlosz
stassats: n is the number of values in the values glob - its totally equivalent to the sbcl representation since that's basically a stack offset into the start of the values