** Appologies, wrong forum. Auto-complete filled the wrong address and I didn't notice **

On 8 March 2012 21:40, Manu <turkeyman@gmail.com> wrote:

> I find myself really wishing for proper multiple return values almost
> every day, particularly when I work with maths heavy code, and especially
> for efficiently returning error codes in functions I'd rather not throw
> from.
> Many maths-y functions return some sort of pair; intersections return
> (ray, t) or something of that type.
> I'm finding HEAPS of SIMD functions want to return pairs (unpacks in
> particular): int4 (low, hight) = unpack(someShort8);
> Currently I have to duplicate everyting: int4 low =
> unpackLow(someShort8); int4 high = unpackHigh(someShort8);
> I'm getting really sick of that, it feels so... last millennium.
>
> The point of 'proper' multiple return values is to return each value in
> registers, in its own register type, using exactly the same register
> assignment pattern as when passing args TO functions.
> I don't think this causes any side effects to the ABI, since the arg
> registers are already volatile across function calls in the first place.
> It just means that the returned-to function can find its return
> values already conveniently in an appropriate register, avoiding memory
> access.
>
> People argue I should return a tuple, but this isn't really the same, it
> has hidden implications that complicate the optimisation potential. For
> instance, tuples have an implicit structure/memory layout which can't be
> ignored, whereas return values don't have memory allocated, ie, you can't
> take the address of a return value without first assigning it to some local
> syntactically.
> The implementation of efficient tuple return values would be much more
> complicated I would imagine too, and the rules are less clear; I can't
> intuitively presume what behaviour returning a tuple of different things
> should actually have in terms of register assignment. I also know precisely
> how multiple return values should work, because it is exactly the same as
> passing arguments to the function, but in reverse.
>
> ... just saying :)
>