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