libera/#clasp - IRC Chatlog
Search
18:06:03
Colleen
karlosz: drmeister said 17 hours, 26 minutes ago: I just realized I'd need to expose stack manipulation functions, closure slot accessing functions, and multiple-value accessing functions if we want to implement the VM in Common Lisp for testing. Should I?
18:07:08
karlosz
we already have an implementation independent prototype vm for the bytecode machine which does weird stuff like emulate pointers and pointer arithmetic with array indices. it's not great
18:07:28
karlosz
interior pointers into the stack/bytecode array/literals array make way more sense in C++
18:12:22
drmeister
Ok, then we are all agreed. The VM bytecode machine will be implemented in C++ from the start.
18:13:03
drmeister
I'd like to implement a couple of instructions, like (NIL) and (RETURN) to get started.
18:15:15
Bike
the current compiler doesn't do declarations at all, and that's the part that makes let* annoying to compile
18:15:35
Bike
i've been distracted by cclasp stuff, but i should be able to do that, especially since aclasp already has the code for it
18:22:41
karlosz
aux doesn't need that declaration stuff but i figured it might share a big chunk of code with let*
21:00:02
karlosz
it was a mistake to make the function for a function call be at the top of the stack
21:00:25
karlosz
even though in CL the function can be "evaluated" out of order with the args, this isn't true for multiple value call or funcall
21:00:36
karlosz
and it doesn't really hurt to change it to be bottom of stack, that's how clisp does it to
21:28:24
Bike
it would probably behoove us to support a direct call special operator a la cleavir-primop:funcall. i think aclasp might already support that even
22:55:53
karlosz
drmeister: we were compiling (f x y z) with (PUSH X) (PUSH Y) (PUSH Z) (PUSH F) (CALL)
22:56:23
karlosz
but really it makes more sense to do (PUSH F) (PUSH X) (PUSH Y) (PUSH Z) (CALL) because funcall evaluates its first argument (the function) before everything els
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