freenode/#clasp - IRC Chatlog
Search
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?
23:01:21
karlosz
alright, so i got (compile nil '(lambda (x) (car (the cons x)))) folding the cons check
23:01:46
karlosz
the trick is just to make meta-evaluate push the type of the definition of LETI onto all its readers as the derived type
23:02:28
karlosz
since if you have (let ((x ...)) (+ x x x x))) obviously each reference of X is of type whatever X is bound as
23:19:10
karlosz
without the type database for known functions we're not going to be able to know how to warn at compile time that that's a conflict
0:12:47
Bike
my vague idea for the car type thing was - we declare car's ftype so that it takes a list. cst-to-ast inserts a THE for that declaration, with source listed as wherever the type proclamation is. then in ast-to-bir, it sees (the list (the (or symbol fixnum) ...)), computes that it's bottom, and spits out a warning that the two types conflict, along with their two source locations.
0:16:58
Bike
yeah, i mean for that particular case it would be in ast-for-bir, for type inference it would be elsewhere
0:17:14
Bike
either that or you have the bir reflect multiple type declarations without conjoining them?
0:19:42
karlosz
we don't have the final types of everything until bir is done running, so that seems like the natural point in time to flame about type conflicts
4:51:16
Bike
so decay_t<some array type>::type is the appropriate pointer type? something like that.