On 8 March 2012 22:13, H. S. Teoh <[email protected]> wrote: > On Thu, Mar 08, 2012 at 10:08:41PM +0200, Manu 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. > [...] > > Couldn't you just use ref parameters? Or does the compiler turn them > into pointers? >
ref parameters are pointers by definition. That's not what I'm talking about.
