freenode/#clasp - IRC Chatlog
Search
15:08:18
Bike
ok, i have local calls with &rest working now... no provision for dx-allocating the rest list, though
15:18:43
Bike
the alternate route to cleaning up c-n-m would be optimizing local functions that take &rest but then just apply it
16:21:09
Bike
i guess we could take care of it just by inlining &rest so that it inserts a call to list or something, and then put in a transform for (apply ... (list ...)) => (funcall ... ...)
16:21:36
Bike
or like sbcl does, (apply ... (list ...)) = (multiple-value-call ... (values-list (list ...))), and then (values-list (list ...)) => (values ...)
16:42:00
drmeister
Wait - what? You want to dump the list into the multiple-value-return area? Interesting...
16:43:54
Bike
i don't want to do that. it's just that sbcl converts apply into multiple-value-call so that it only has one unknown-argcount call type to deal with
16:44:45
Bike
(flet ((foo (&rest args) (apply #'bar args))) (foo 1 2 3)). it would be nice to rewrite that as (bar 1 2 3)
16:45:59
Bike
also i'm trying to figure out how sbcl does multiple-value-call with multiple argforms and man i don't get this at all. i'm down in the vops now
16:48:39
Bike
the slightly more practical idea would be having (flet ((call-next-method (&rest args) (apply cont (or args method-args)))) ... (call-next-method) ...) efficiently end up as (... (funcall cont method-args) ...) without all our weird crap about walkers and macrolet
17:12:07
Bike
i guess... since sbcl does unknown-values returns on the stack, more calls will just keep adding to that stack? i think?
17:47:27
Bike
function returns where the caller and callee don't coordinate how many return values there are
17:53:57
drmeister
You know what - you know what you are doing. I'll just sit quietly in the peanut gallery.
18:12:51
karlosz
but the stack pointer is reset in the caller on return after the caller "receives" the mv values
18:15:49
karlosz
going to get rid of the ctype slot on datum and move it to linear-datum as derived-type
18:41:46
Bike
drmeister: as far as i know each new multiple value return starts putting them in again at the beginning?
19:12:02
karlosz
alright, well now that im actually doing the type thing i understand what Python is doing when they say that they won't eliminate once used LET variables
19:12:42
karlosz
if you do (defun f (x) (let ((y x)) (the cons y)))) you don't want to lose the type assertion on y
19:35:45
karlosz
(compile nil '(lambda (x) (if (cleavir-primop:typeq (the cons x) cons) 3 4))) now eliminates the typeq
19:42:24
karlosz
(car (the cons x)) unfortunately doesn't work because of the way we compile down car by inlining
20:10:01
drmeister
Bike: You are correct - we could add a sort of fill-pointer for multiple value return - would that be helpful? FYI There is a sort of unused zeroth multiple-return value space in the multiple value return vector and so that would make a fill-pointer easier to implement. The value can later be read out and return in the register return part..
20:12:10
drmeister
Yeah - and is that a good enough reason to implement a multiple-value return fill-pointer?
20:15:48
Bike
here's what i'd imagine: when functions return values into the mv vector, they start putting them in at fillpointer+1, where fillpointer starts at 0, and then set fillpointer. multiple-to-fixed or suchlike sets the fillpointer back to 0. multiple-value-call iterates through the argforms as they fill up the vector, and inserts the xtra primary return values as it goes. then at the end it does what it does now
20:17:31
drmeister
Ah - interesting - then it's multiple-value-call's responsibility to spill the zeroth return value returned in a register into the appropriate slot in the multiple-value return vector?
20:17:52
Bike
right. that way we can keep the current protocol where functions don't bother storing the zeroth return value.
20:19:16
Bike
well, it means between calls you have to set the fill pointer back to zero... but i guess that can be skipped unless more than one value was returned
20:19:29
drmeister
And the number of returned values is in a register and multiple-value-call uses that to increment the fill-pointer.
20:22:21
drmeister
when functions return values into the mv vector, they start putting them in at fillpointer+1, ... but they don't set the fillpointer. we have multiple-value-call iterate through the argforms as they fill up the vector and update the fillpointer at the same time that it inserts the xtra primary return value as it goes?
20:22:56
drmeister
Do you see any problems with that? I'm just taking your idea and applying it again.
20:27:50
drmeister
Uh - we already have a fill-pointer - we could probably speed multiple value returns up
20:28:22
drmeister
https://github.com/clasp-developers/clasp/blob/master/include/clasp/core/multipleValues.h#L119
20:29:10
drmeister
In the Values functions we are resetting the fillpointer with me.setSize(0) and then using emplace_back and writing the return values and incrementing the fillpointer.
20:29:22
drmeister
https://github.com/clasp-developers/clasp/blob/master/include/clasp/core/multipleValues.h#L70
21:19:20
drmeister
I attempting to change the Values(...) functions in clasp so they work like this:
21:20:16
drmeister
Wait - currently we depend on the _FillPointer to be updated at the end of these Values(...) functions - I'll fix that.
21:23:43
drmeister
Yeah - so that needs to be fixed. We need to remove every use of the MultipleValues::_FillPointer in the system and fix any code that breaks when doing that. The only thing that should update the _FillPointer should be multiple-value-call.
21:26:34
drmeister
Because if anyone else updates the _FillPointer then every function call that returns values will need to update _FillPointer.
21:27:10
drmeister
We do that now - we do even more than that - we increment the _FillPointer with every value that is returned in the multiple-values buffer. I'm fixing at least that now.
21:43:17
karlosz
when i change class readvar to constant-reference the initialize-instance method doesn't seem to fire
21:45:32
specbot
update-instance-for-different-class: http://www.lispworks.com/reference/HyperSpec/Body/f_update.htm
21:49:11
karlosz
if i use shared-initialize, it will work for both change class and the normal initialization right?
21:49:43
karlosz
so we should be changing initialize-instance :after methods to shared intiailize methods i guess
21:50:36
karlosz
i mean i think change-class is going to be good when we want to substitute computations
21:50:53
karlosz
replace computation only replaces the uses but you still need to insert the thing again
22:00:15
Bike
i'm not sure i'm even at that level of things. but i don't think i understand the question
22:00:42
Bike
i have it calling the main entry point, and the first couple arguments are the same (mapcar #'variable-as-argument environment) dealie.
22:00:48
karlosz
for a local call, we pass all the environment values and cells at the beginning of the call
22:01:03
Bike
but it looks like somehow a call instruction is feeding into a fixed-to-multiple instruction?
22:22:02
Bike
i have main entry point calls for local mv-calls now... needs some work to handle &rest, but i have a plan
22:30:39
Bike
single vlaue local calls can handle &rest (with some changes i haven't pushed) but it would still call the list function, i suppose...
22:37:27
karlosz
Bike: so if im reading this right, we just don't inline anything declared inline that we build, right?
22:37:55
karlosz
like all the inline definitions in Eclector or BIR or Concrete-Syntax-Tree are just not saved or inlined even in the final image?