** Appologies, wrong forum. Auto-complete filled the wrong address and I didn't notice **
On 8 March 2012 21:40, Manu <turkey...@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 :) >
