libera/#clasp - IRC Chatlog
Search
19:55:19
karlosz
the entry_pc vector doesn't need to have byte offsets, it could just have the pc address directly
19:55:51
karlosz
i mean its more efficient for the vm to have pc addresses directly, so it can just copy that into the vm.pc slot
19:57:30
drmeister
So I have 7 trampoline functions that you jump into and they lookup the bytecode index and start interpreting from that.
20:02:15
drmeister
https://github.com/clasp-developers/clasp/blob/main/include/clasp/core/functor.h#L120
20:03:03
drmeister
You want bytecode_function to be pointed to by bytecode_closure. That matches the EntryPointBase_O objects.
20:03:44
drmeister
The EntryPointBase_O objects have pointers to code that handles the various entry points.
20:04:17
drmeister
You enter the entry points with a pointer to the closure object and we use that to get a pointer to the entry-point object.
20:04:47
drmeister
bytecode_function info should go into a EntryPoint_O subclass tailored for bytecode.
20:05:33
drmeister
We have a LocalEntryPoint_O object for local compiled functions. https://github.com/clasp-developers/clasp/blob/main/include/clasp/core/functor.h#L150
20:06:13
drmeister
general/external functions use this... https://github.com/clasp-developers/clasp/blob/main/include/clasp/core/functor.h#L177
20:08:29
karlosz
drmeister: i don't think local bytecode functions are necessary to get things working at this point
20:16:04
karlosz
drmeister: if 0 is the general entry point, does the fixed arity of 0 get its own entry point at 1?
21:55:45
Bike
alright, this svref sequence is less llvm ir than calling svref is, so that should be fine bloatwise hopefully
21:56:00
Bike
and it's the same number of function calls, except this one's a c api call instead of lisp
23:33:17
karlosz
now that im actually getting into implementing the 1 stack solution (sounds vaguely political) in the prototype vm, its getting me thinking about how we want to bounce around between native and bytecode functions a bit more
23:34:04
karlosz
like, when calling a bytecode function from a bytecode function, it would be nice not to have to reinitialize the vm struct every time
23:34:57
karlosz
i suppose with stack segments you'd still get exactly the same context switch overhead. with stack segments you'd just be allocating a new stack on every bytecode entry and you'd also basically have to reload stuff like the current bytecode vector/literals/closure
0:34:04
Bike
oh geez, obvious optimization i just noticed i've been missing, (make-sequence whatever (length whatever)) actually checks that the length is nonnegative
3:09:13
drmeister
Create a function-description, create a bytecode-module, create a global-bytecode-entry-point and then create the bytecode-closure
3:51:05
drmeister
https://github.com/clasp-developers/clasp/wiki/Virtual-machine-design#creating-bytecode-closures