libera/#clasp - IRC Chatlog
Search
0:38:14
karlosz
got FLET working in the bytecode compiler prototype. it was pretty simple (just treating it like lambda basically). labels will be slightly more annoying
0:53:17
drmeister
We can add bytecode closures now and run them. There is a function called `bytecode_call` that we will write the bytecode interpreter within.
0:55:06
yitzi
drmeister: This seems like some leftover debugging stuff. https://github.com/clasp-developers/clasp/blob/48c807355954b8664b3d7b866b0f3d4a17f99e62/include/clasp/llvmo/code.h#L462-L465
0:57:37
Bike
oh yeah, on that note, drmeister, i don't want to be pedantic but when you write a printf string can you be sure to use portable format specifiers? like you have lu for a size_t there but it should be zu. as soon as we go from mac to linux or vice versa clang starts complaining
0:59:06
drmeister
yitzi: No - I don't think that's for debugging. There are requirements that the names of memory buffers in llvm be unique - I think I use that function as part of it.
1:01:22
drmeister
yitzi: https://github.com/clasp-developers/clasp/blob/vm/src/llvmo/llvmoExpose.cc#L182
1:11:01
Bike
i sometimes worry that prospective chemists are going to see all that kind of thing and get scared off
1:12:48
yitzi
Not in the web interface. They can see it in the console that they use to start Jupyter. If they care.
2:13:06
karlosz
drmeister: is there a reason to make it grow down besides the fact that that's what C++ does?
2:15:39
drmeister
We evaluate function arguments last to first and so all you need to do is evaluate argument and then push it?
2:18:41
karlosz
We evaluate function arguments first to last - you are not allowed to do it in the other order in CL
2:25:30
karlosz
still confused what the plan for lambda lists and entry points is. i wrote up in the spec what i think are needed to handle lambda lists
2:26:22
karlosz
i looked over drmeister s commit and i wasn't sure with how the entry points are supposed to mesh with bytecode function template's entry pcs
2:27:03
Bike
i haven't done anything on that front. pretty much spent the day staring at the compiler (cclasp, not the vm)
2:28:19
karlosz
because the vm stack and dynenv stack are different entities for the bytecode interpreter at least
2:29:46
Bike
the stack of dynenvs is a bunch of stack-allocated conses linked from the thread local data structure
2:30:21
drmeister
Oh first to last is it? I knew that (implemented it a couple of times) and then forgot.
2:30:42
Bike
that's why i wrote about the vm stack distinctly from the dynenv stack on the wiki page
2:34:49
karlosz
Bike: okay cool, that makes sense then. so it does form a separate "stack" on the thread local data structure
2:35:27
Bike
like when you pop a dynenv, that's looking at the current stack cons and taking the cdr, is all
2:35:39
karlosz
drmeister: at the bottom of the page here i specified what goes in a function template: https://github.com/clasp-developers/clasp/wiki/Virtual-machine-design
2:36:07
karlosz
the entry points there correspond to program counter offsets into the bytecode vector (for the 0th arg entry point, 1st arg entry point, etc)
2:36:35
karlosz
there's an example for how a function with an &optional lambda list gets compiled down to bytecode in the section Lambda list instructions
2:37:04
drmeister
In here? https://github.com/clasp-developers/clasp/wiki/Virtual-machine-design#vm-struct-definitions
2:38:08
karlosz
that struct represents the template for a closure, since closures with different environments share the same function template
2:39:08
karlosz
this section https://github.com/clasp-developers/clasp/wiki/Virtual-machine-design#vm-struct-definitions shows an example of how a complicated lambda list gets compiled down to bytecode and how the entry_pcs slot would get used
2:39:11
drmeister
I don't understand - where is all that information supposed to be stored? In a Closure_O object? That's where I was putting it.
2:41:05
drmeister
karlosz: Sure, for now we stick it in first slots in the ClosureWithSlots_O object.
2:41:36
karlosz
so if you have two closure objects with the same function template, in clasp right now they are represented by having all the slots copied?
2:42:33
karlosz
struct bytecode_module = BytecodeModule_O, struct bytecode_closure = BytecodeClosureWithSlots_O, struct bytecode_function = ????
2:50:13
drmeister
I'm renaming classes at the moment - so things are a bit more complicated to explain. But bytecode_closure will be BytecodeClosure_O with everything you want in it.
2:51:19
karlosz
if you had multiple closures where the only thing that's different is the environment, there's no reason to waste space and have a bunch of the fields duplicated
2:52:10
karlosz
so creating a closure is easy: you just bundle up the function template with the environment, rather than copying everything
2:54:33
drmeister
Oh - maybe not. Let me think on that. There is a lot of information in the FunctionDescription_O object
2:56:01
drmeister
Why do you need required, optional, rest_slot, key_start and flags for &rest, &key, &allow-other-keys?
3:01:32
drmeister
You are coming at it following what clisp does - I'm coming at it from what I did for the interpreter and aclasp/bclasp and C++ wrapping works.
3:05:41
drmeister
I'll walk you through how the LambdaListHandler_O object works in a few days once I refresh my memory and we can all get on zoom
3:06:42
drmeister
If it looks too inefficient we take a look through the clisp approach or something else.
3:09:14
drmeister
It's a class that contains everything the system needs to turn a vector of caller arguments to a vector of callee arguments and it uses integer indices for everything.
3:12:41
karlosz
ah yeah, that's basically intepreting lambda lists instead of bytecode compiling some of the dispatch work away
3:14:33
Bike
i am really pretty sure the lambda list handler is not going to work for our purposes, and that we should do something more like we do in cclasp
3:14:41
drmeister
Yeah, and we can compile the default initializers into bytecode and the LambdaListHandler_O code will evaluate it.
3:16:41
Bike
the lambda list handler is based on eval-ing default forms and stuff. it has control of the interpreter. it will not have control of the bytecode. just running some bytecode and then returning back into the handler doesn't make sense. why not just transfer control into the bytecode entirely?
3:21:41
drmeister
LambdaListHandler_O would work though, before you enter the bytecode for the function body the LambdaListHandler_O would bind all of the arguments in slots in the side-stack. It would call into bytecode for each of the argument defaults.
3:24:44
Bike
say we have (&optional (a (f)) (b (g))). We compile that into bytecode like "a-default: constant(1) push call return-to-lambda-list-handler; b-default: constant(2) call push return-to-lambda-list-handler;" and then i guess the lambda list handler has to be modified so that it can pop the value from the vm and set it up in the right place in the vm stack, which it would also have to be taught about
3:25:02
drmeister
Indeed, in cclasp we bypass LambdaListHandler_O by recompiling the lambda lists for all the builtin functions.
3:26:02
drmeister
Let me refresh my memory about how it will work and then I'll propose it to you both.
3:28:31
drmeister
Here's an idea - if bytecode can do lambda list processing better than LambdaListHandler_O then we could compile lambda-lists for builtin functions into bytecode.
3:30:28
Bike
i just don't think we could practically do very much code reuse. we'd already have to make a lot of changes to both lambda list handler and the bytecode to let them interoperate.
3:36:45
Bike
well we can figure it out later... i'm going to sleep now. good night, see you tomorrow
11:16:23
yitzi
Looks like the nightly builds failed. Appears that the static analyzer needs to be run. Doing so on zeus now.