libera/#clasp - IRC Chatlog
Search
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