------=_Part_689_23691814.1402364969139
Content-Type: text/plain; charset=UTF-8

I work on the Mill CPU, a novel architecture for general-purpose
computation. The Mill hardware has a number of features that are not
present in current CPUs, and we plan to implement extensions in clang and
gcc to accommodate those aspects that do not fit naturally as libraries or
intrinsics. We want our extensions to be "C++-ish" in style, and to conform
to best-practice thinking if there is any. Info on the Mill at
http://millcomputing.com/docs.

One of the Mill features is the ability for Mill hardware to return more
than one result from a function. These are true value returns, not
reference arguments. If a returned value is a large object then we uses the
same implicit reference trick as is used for large function arguments, but
anything that would pass in the registers on a conventional CPU can be
returned by value on the Mill. VARRESULTS is also supported using a
mechanism similar to VARARGS. For a use-case, we find a very common idiom
is for a function to have one main value result and a second status result.
However, multiple value results are often convenient or efficient too; for
example, it is possible to compute both sin() and cos() of an angle in
little more than the time to compute one of them. The library function
computes and returns both, and the caller uses one or the other or both as
needed.

The question is how this facility should be integrated (as an extension)
into the language. Languages (such as Ada) that have OUT parameters have a
natural way to express return-by-value, so something like:

            int foo(int x, int y, _out int z) { ...}

would provide declarator syntax. However, it's not at all clear how to
extend the return statement; tuples would be ungainly, and the natural
argument list runs foul of the comma operator. There are also evaluation
order issues: should the actual argument of an OUT parameter be evaluated
before or after the call?

A different approach, followed by some other languages, uses modified
function-like notation for multiple results, possibly something like:

            {int, int} foo(int x, int y) {...};

which seems more C++-flavored than the out-parameter approach. However, the
return statement remains a problem, and in addition the syntactic place of
a function call becomes problematic. Possibly:

            a = b + {*, c}foo(1,2);  // means that first result is used in
the add, while the second is assigned to c

seems tolerable, but potentially forces the creation of otherwise
unnecessary placeholder variables.

Has C++ multi-result syntax and semantics been explored before? Can anyone
supply citations?

Ivan Godard

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_689_23691814.1402364969139
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I work on the Mill CPU, a novel architecture for general-p=
urpose computation. The Mill hardware has a number of features that are not=
 present in current CPUs, and we plan to implement extensions in clang and =
gcc to accommodate those aspects that do not fit naturally as libraries or =
intrinsics. We want our extensions to be "C++-ish" in style, and to conform=
 to best-practice thinking if there is any. Info on the Mill at http://mill=
computing.com/docs.<br><br>One of the Mill features is the ability for Mill=
 hardware to return more than one result from a function. These are true va=
lue returns, not reference arguments. If a returned value is a large object=
 then we uses the same implicit reference trick as is used for large functi=
on arguments, but anything that would pass in the registers on a convention=
al CPU can be returned by value on the Mill. VARRESULTS is also supported u=
sing a mechanism similar to VARARGS. For a use-case, we find a very common =
idiom is for a function to have one main value result and a second status r=
esult. However, multiple value results are often convenient or efficient to=
o; for example, it is possible to compute both sin() and cos() of an angle =
in little more than the time to compute one of them. The library function c=
omputes and returns both, and the caller uses one or the other or both as n=
eeded.<br><br>The question is how this facility should be integrated (as an=
 extension) into the language. Languages (such as Ada) that have OUT parame=
ters have a natural way to express return-by-value, so something like:<br>&=
nbsp;<br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; int foo(int x, int y, _o=
ut int z) { ...} <br><br>would provide declarator syntax. However, it's not=
 at all clear how to extend the return statement; tuples would be ungainly,=
 and the natural argument list runs foul of the comma operator. There are a=
lso evaluation order issues: should the actual argument of an OUT parameter=
 be evaluated before or after the call?<br><br>A different approach, follow=
ed by some other languages, uses modified function-like notation for multip=
le results, possibly something like:<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; {int, int} foo(int x, int y) {...};<br>=
<br>which seems more C++-flavored than the out-parameter approach. However,=
 the return statement remains a problem, and in addition the syntactic plac=
e of a function call becomes problematic. Possibly:<br><br>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a =3D b + {*, c}foo(1,2)=
;&nbsp; // means that first result is used in the add, while the second is =
assigned to c<br><br>seems tolerable, but potentially forces the creation o=
f otherwise unnecessary placeholder variables.<br><br>Has C++ multi-result =
syntax and semantics been explored before? Can anyone supply citations?<br>=
<br>Ivan Godard<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_689_23691814.1402364969139--

.