www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Multiple return values...

reply Manu <turkeyman gmail.com> writes:
--002354471058a2e89f04bac0d7f0
Content-Type: text/plain; charset=UTF-8

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 :)

--002354471058a2e89f04bac0d7f0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<span style>I find myself really wishing for proper multiple return values =
almost every day, particularly when I work with maths heavy code, and espec=
ially for efficiently returning error codes in functions I&#39;d rather not=
 throw from.</span><div style>
Many maths-y functions return some sort of pair; intersections return (ray,=
 t) or something of that type.</div><div style>I&#39;m finding HEAPS of SIM=
D functions want to return pairs (unpacks in particular):=C2=A0int4 (low, h=
ight) =3D unpack(someShort8);</div>
<div style>Currently I have to duplicate everyting: int4 low =3D unpackLow(=
someShort8);=C2=A0int4 high =3D unpackHigh(someShort8);</div><div style>I&#=
39;m getting really sick of that, it feels so... last millennium.</div><div=
 style>
<div><br></div><div>The point of &#39;proper&#39; 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.</d=
iv>
<div>I don&#39;t think this causes any side effects to the ABI, since the a=
rg registers are already volatile across function calls in the first place.=
</div><div>It just means that the returned-to function can find its return =
values=C2=A0already=C2=A0conveniently in an appropriate register, avoiding =
memory access.</div>
<div><br></div><div>People argue I should return a tuple, but this isn&#39;=
t really the same, it has hidden implications that complicate the optimisat=
ion potential. For instance, tuples have an implicit structure/memory layou=
t which can&#39;t be ignored, whereas return values don&#39;t have memory a=
llocated, ie, you can&#39;t take the address of a return value without firs=
t assigning it to some local syntactically.</div>
<div>The implementation of efficient tuple return values would be much more=
 complicated I would imagine too, and the rules are less clear; I can&#39;t=
 intuitively presume what behaviour returning a tuple of different things s=
hould actually have in terms of register assignment. I also know precisely =
how multiple return values should work, because it is exactly the same as p=
assing arguments to the function, but in reverse.</div>
<div><br></div><div>... just saying :)</div></div>

--002354471058a2e89f04bac0d7f0--
Mar 08 2012
parent "a" <a a.com> writes:
 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.

It can also be realy inefficient. For example ARM NEON has vzip instruction that is used like this: vzip.32 q0, q1 This will interleave elements of vectors in q0 and q1 in one instruction.
Mar 09 2012