Topic: Integrating multiple-result function call
Author: David Krauss <potswa@gmail.com>
Date: Tue, 10 Jun 2014 09:50:47 +0800
Raw View
On 2014-06-10, at 9:49 AM, ivan@ootbcomp.com wrote:
> http://millcomputing.com/docs.
403 forbidden error.
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 10 Jun 2014 10:07:40 +0800
Raw View
--Apple-Mail=_2E010152-E066-439B-ABD8-A5894C82F2A7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-06-10, at 9:49 AM, ivan@ootbcomp.com wrote:
> Has C++ multi-result syntax and semantics been explored before? Can anyon=
e supply citations?
The simplest analogy is returning a class type by value. This has existed s=
ince before C++ split from C. The C++ standard library functions std::equal=
_range (and its associative container counterpart), std::mismatch, and othe=
rs (including the C standard library function family *div()) return multipl=
e values this way.
You can also perform lifetime analysis on instructions pulled in by functio=
n inlining, and promote a pass-by-reference parameter to registers.
Generally speaking, CPU architectures do not dictate that a single register=
holds a function return value. Any of x86, x64, 68K, and PowerPC allow mul=
tiple general-purpose registers to be preserved on return, and those are on=
ly the ones I personally know. It's a choice made by the ABI, guided by sta=
tistics. One register provides sufficient storage for 90% of function calls=
.. Function returns are uncommon enough to render useless any special archit=
ectural considerations, aside from preventing extremely expensive condition=
s like pipeline flushes and branch mispredictions.
--=20
---=20
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 e=
mail 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-proposa=
ls/.
--Apple-Mail=_2E010152-E066-439B-ABD8-A5894C82F2A7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06–10, at 9:49 AM, <a href=3D"mailto:ivan@ootbcomp.com">ivan@oo=
tbcomp.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><blockqu=
ote type=3D"cite"><div dir=3D"ltr">Has C++ multi-result syntax and semantic=
s been explored before? Can anyone supply citations?<br></div></blockquote>=
</div><br><div>The simplest analogy is returning a class type by value. Thi=
s has existed since before C++ split from C. The C++ standard library funct=
ions std::equal_range (and its associative container counterpart), std::mis=
match, and others (including the C standard library function family <font f=
ace=3D"Courier">*div()</font>) return multiple values this way.</div><div><=
br></div><div>You can also perform lifetime analysis on instructions pulled=
in by function inlining, and promote a pass-by-reference parameter to regi=
sters.</div><div><br></div><div>Generally speaking, CPU architectures do no=
t dictate that a single register holds a function return value. Any of x86,=
x64, 68K, and PowerPC allow multiple general-purpose registers to be prese=
rved on return, and those are only the ones I personally know. It’s a=
choice made by the ABI, guided by statistics. One register provides suffic=
ient storage for 90% of function calls. Function returns are uncommon enoug=
h to render useless any special architectural considerations, aside from pr=
eventing extremely expensive conditions like pipeline flushes and branch mi=
spredictions.</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--Apple-Mail=_2E010152-E066-439B-ABD8-A5894C82F2A7--
.
Author: Ivan Godard <ivan@MillComputing.com>
Date: Mon, 09 Jun 2014 19:23:12 -0700
Raw View
Odd. Works for me, and it's a public site.
On 6/9/2014 6:50 PM, David Krauss wrote:
> On 2014-06-10, at 9:49 AM, ivan@ootbcomp.com wrote:
>
>> http://millcomputing.com/docs.
> 403 forbidden error.
>
--
---
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/.
.
Author: Ivan Godard <ivan@MillComputing.com>
Date: Mon, 09 Jun 2014 19:29:39 -0700
Raw View
This is a multi-part message in MIME format.
--------------070607060308020305090608
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
We know why other CPUs do not have hardware support, but that's not the
issue: right or wrong, we do have such support. The question is how to
make it naturally available as an extension of C++.
And yes, with sufficient analysis the compiler may bbe able to figure
out in some (many?) cases that a regular C++ single-valued function can
use the hardware operation, but that too is not the issue: we are
looking for a language extension by which the programmer can state his
intention that the function has some specific number of results other
than zero or one, whether or not the compiler could figure it out.
Without requiring bogus dummy class types, or detecting that a reference
type is really not a reference type, or other kludgery.
On 6/9/2014 7:07 PM, David Krauss wrote:
>
> On 2014--06--10, at 9:49 AM, ivan@ootbcomp.com
> <mailto:ivan@ootbcomp.com> wrote:
>
>> Has C++ multi-result syntax and semantics been explored before? Can
>> anyone supply citations?
>
> The simplest analogy is returning a class type by value. This has
> existed since before C++ split from C. The C++ standard library
> functions std::equal_range (and its associative container
> counterpart), std::mismatch, and others (including the C standard
> library function family *div()) return multiple values this way.
>
> You can also perform lifetime analysis on instructions pulled in by
> function inlining, and promote a pass-by-reference parameter to registers.
>
> Generally speaking, CPU architectures do not dictate that a single
> register holds a function return value. Any of x86, x64, 68K, and
> PowerPC allow multiple general-purpose registers to be preserved on
> return, and those are only the ones I personally know. It's a choice
> made by the ABI, guided by statistics. One register provides
> sufficient storage for 90% of function calls. Function returns are
> uncommon enough to render useless any special architectural
> considerations, aside from preventing extremely expensive conditions
> like pipeline flushes and branch mispredictions.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/4g3NYpKwQX0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--
---
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/.
--------------070607060308020305090608
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
We know why other CPUs do not have hardware support, but that's not
the issue: right or wrong, we do have such support. The question is
how to make it naturally available as an extension of C++.<br>
<br>
And yes, with sufficient analysis the compiler may bbe able to
figure out in some (many?) cases that a regular C++ single-valued
function can use the hardware operation, but that too is not the
issue: we are looking for a language extension by which the
programmer can state his intention that the function has some
specific number of results other than zero or one, whether or not
the compiler could figure it out.<br>
<br>
Without requiring bogus dummy class types, or detecting that a
reference type is really not a reference type, or other kludgery.<br>
<br>
<br>
<div class="moz-cite-prefix">On 6/9/2014 7:07 PM, David Krauss
wrote:<br>
</div>
<blockquote
cite="mid:C16B52A2-2A63-469C-9E43-6558498CABAA@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On 2014–06–10, at 9:49 AM, <a moz-do-not-send="true"
href="mailto:ivan@ootbcomp.com">ivan@ootbcomp.com</a> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<div dir="ltr">Has C++ multi-result syntax and semantics been
explored before? Can anyone supply citations?<br>
</div>
</blockquote>
</div>
<br>
<div>The simplest analogy is returning a class type by value. This
has existed since before C++ split from C. The C++ standard
library functions std::equal_range (and its associative
container counterpart), std::mismatch, and others (including the
C standard library function family <font face="Courier">*div()</font>)
return multiple values this way.</div>
<div><br>
</div>
<div>You can also perform lifetime analysis on instructions pulled
in by function inlining, and promote a pass-by-reference
parameter to registers.</div>
<div><br>
</div>
<div>Generally speaking, CPU architectures do not dictate that a
single register holds a function return value. Any of x86, x64,
68K, and PowerPC allow multiple general-purpose registers to be
preserved on return, and those are only the ones I personally
know. It’s a choice made by the ABI, guided by statistics. One
register provides sufficient storage for 90% of function calls.
Function returns are uncommon enough to render useless any
special architectural considerations, aside from preventing
extremely expensive conditions like pipeline flushes and branch
mispredictions.</div>
<div><br>
</div>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in
the Google Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a moz-do-not-send="true"
href="https://groups.google.com/a/isocpp.org/d/topic/std-proposals/4g3NYpKwQX0/unsubscribe">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/4g3NYpKwQX0/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email
to <a moz-do-not-send="true"
href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send="true"
href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send="true"
href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------070607060308020305090608--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 10 Jun 2014 10:32:01 +0800
Raw View
Apparently I have been blocked by "project honey pot."
You might consider an established host like GitHub.
On 2014-06-10, at 10:23 AM, Ivan Godard <ivan@MillComputing.com> wrote:
> Odd. Works for me, and it's a public site.
>
>
> On 6/9/2014 6:50 PM, David Krauss wrote:
>> On 2014-06-10, at 9:49 AM, ivan@ootbcomp.com wrote:
>>
>>> http://millcomputing.com/docs.
>> 403 forbidden error.
>>
>
> --
>
> --- 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/.
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 10 Jun 2014 10:43:38 +0800
Raw View
--Apple-Mail=_44207E11-0A98-4EDB-801A-3686E139621E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-06-10, at 10:29 AM, Ivan Godard <ivan@MillComputing.com> wrote:
> We know why other CPUs do not have hardware support
Other CPUs do support multiple returns, at the hardware level. How do they =
not? Can you name a single problem on a single architecture? On x64 specifi=
cally?
> , but that's not the issue: right or wrong, we do have such support. The =
question is how to make it naturally available as an extension of C++.
You asked for existing practice and literature. If extending the language i=
s part of your homework assignment, so be it, but again you need to state w=
hat difference needs to be made.
> And yes, with sufficient analysis the compiler may bbe able to figure out=
in some (many?) cases that a regular C++ single-valued function can use th=
e hardware operation, but that too is not the issue: we are looking for a l=
anguage extension by which the programmer can state his intention that the =
function has some specific number of results other than zero or one, whethe=
r or not the compiler could figure it out.
>=20
> Without requiring bogus dummy class types, or detecting that a reference =
type is really not a reference type, or other kludgery.
If you dig into implementations of other multiple-return languages such as =
Python, Haskell, ML, etc, you will find that multiple return values are alw=
ays implemented as single values of tuple type. Nothing is lost in such a f=
ormalism so there's no reason not to model things that way. All that C++ la=
cks is declarations that unpack tuples. Such a feature is hard to reconcile=
with the C legacy of declarations supporting introduction of multiple name=
s of the same type. But, we will probably see it added eventually.
However, that's only syntactic sugar and there's no bearing on machine arch=
itecture. C++ is entirely machine independent and machine-specific extensio=
ns are outside the scope of this discussion list.
--=20
---=20
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 e=
mail 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-proposa=
ls/.
--Apple-Mail=_44207E11-0A98-4EDB-801A-3686E139621E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06–10, at 10:29 AM, Ivan Godard <<a href=3D"mailto:ivan@Mill=
Computing.com">ivan@MillComputing.com</a>> wrote:</div><br class=3D"Appl=
e-interchange-newline"><blockquote type=3D"cite">
=20
<meta content=3D"text/html; charset=3DISO-8859-1" http-equiv=3D"Content=
-Type">
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
We know why other CPUs do not have hardware support</div></blockquote><=
div><br></div><div>Other CPUs <i>do</i> support multiple returns, at t=
he hardware level. How do they not? Can you name a single problem on a sing=
le architecture? On x64 specifically?</div><br><blockquote type=3D"cite"><d=
iv bgcolor=3D"#FFFFFF" text=3D"#000000">, but that's not
the issue: right or wrong, we do have such support. The question is
how to make it naturally available as an extension of C++.<br></div></b=
lockquote><div><br></div><div>You asked for existing practice and literatur=
e. If extending the language is part of your homework assignment, so be it,=
but again you need to state what difference needs to be made.</div><br><bl=
ockquote type=3D"cite"><div bgcolor=3D"#FFFFFF" text=3D"#000000">And yes, w=
ith sufficient analysis the compiler may bbe able to
figure out in some (many?) cases that a regular C++ single-valued
function can use the hardware operation, but that too is not the
issue: we are looking for a language extension by which the
programmer can state his intention that the function has some
specific number of results other than zero or one, whether or not
the compiler could figure it out.<br>
<br>
Without requiring bogus dummy class types, or detecting that a
reference type is really not a reference type, or other kludgery.<br></=
div></blockquote><div><br></div><div>If you dig into implementations of oth=
er multiple-return languages such as Python, Haskell, ML, etc, you will fin=
d that multiple return values are always implemented as single values of tu=
ple type. Nothing is lost in such a formalism so there’s no reason no=
t to model things that way. All that C++ lacks is declarations that unpack =
tuples. Such a feature is hard to reconcile with the C legacy of declaratio=
ns supporting introduction of multiple names of the same type. But, we will=
probably see it added eventually.</div></div><br><div>However, that’=
s only syntactic sugar and there’s no bearing on machine architecture=
.. C++ is entirely machine independent and machine-specific extensions are o=
utside the scope of this discussion list.</div><div><br></div></body></html=
>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--Apple-Mail=_44207E11-0A98-4EDB-801A-3686E139621E--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 10 Jun 2014 10:44:16 +0800
Raw View
--Apple-Mail=_01E0F6CE-0D6A-4A50-816A-A34A87DB272E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-06-10, at 10:29 AM, Ivan Godard <ivan@MillComputing.com> wrote:
> We know why other CPUs do not have hardware support
Other CPUs do support multiple returns, at the hardware level. How do they =
not? Can you name a single problem on a single architecture? On x64 specifi=
cally?
> , but that's not the issue: right or wrong, we do have such support. The =
question is how to make it naturally available as an extension of C++.
You asked for existing practice and literature. If extending the language i=
s part of your homework assignment, so be it, but again you need to state w=
hat difference needs to be made.
> And yes, with sufficient analysis the compiler may bbe able to figure out=
in some (many?) cases that a regular C++ single-valued function can use th=
e hardware operation, but that too is not the issue: we are looking for a l=
anguage extension by which the programmer can state his intention that the =
function has some specific number of results other than zero or one, whethe=
r or not the compiler could figure it out.
>=20
> Without requiring bogus dummy class types, or detecting that a reference =
type is really not a reference type, or other kludgery.
If you dig into implementations of other multiple-return languages such as =
Python, Haskell, ML, etc, you will find that multiple return values are alw=
ays implemented as single values of tuple type. Nothing is lost in such a f=
ormalism so there's no reason not to model things that way. All that C++ la=
cks is declarations that unpack tuples. Such a feature is hard to reconcile=
with the C legacy of declarations supporting introduction of multiple name=
s of the same type. But, we will probably see it added eventually.
However, that's only syntactic sugar and there's no bearing on machine arch=
itecture. C++ is entirely machine independent and machine-specific extensio=
ns are outside the scope of this discussion list.
--=20
---=20
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 e=
mail 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-proposa=
ls/.
--Apple-Mail=_01E0F6CE-0D6A-4A50-816A-A34A87DB272E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/html cha=
rset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-n=
bsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2=
014–06–10, at 10:29 AM, Ivan Godard <<a href=3D"mailto:ivan@=
MillComputing.com">ivan@MillComputing.com</a>> wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite">
=20
<meta content=3D"text/html; charset=3DISO-8859-1" http-equiv=3D"Content=
-Type">
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
We know why other CPUs do not have hardware support</div></blockquote><=
div><br></div><div>Other CPUs <i>do</i> support multiple returns, at t=
he hardware level. How do they not? Can you name a single problem on a sing=
le architecture? On x64 specifically?</div><br><blockquote type=3D"cite"><d=
iv bgcolor=3D"#FFFFFF" text=3D"#000000">, but that's not
the issue: right or wrong, we do have such support. The question is
how to make it naturally available as an extension of C++.<br></div></b=
lockquote><div><br></div><div>You asked for existing practice and literatur=
e. If extending the language is part of your homework assignment, so be it,=
but again you need to state what difference needs to be made.</div><br><bl=
ockquote type=3D"cite"><div bgcolor=3D"#FFFFFF" text=3D"#000000">And yes, w=
ith sufficient analysis the compiler may bbe able to
figure out in some (many?) cases that a regular C++ single-valued
function can use the hardware operation, but that too is not the
issue: we are looking for a language extension by which the
programmer can state his intention that the function has some
specific number of results other than zero or one, whether or not
the compiler could figure it out.<br>
<br>
Without requiring bogus dummy class types, or detecting that a
reference type is really not a reference type, or other kludgery.<br></=
div></blockquote><div><br></div><div>If you dig into implementations of oth=
er multiple-return languages such as Python, Haskell, ML, etc, you will fin=
d that multiple return values are always implemented as single values of tu=
ple type. Nothing is lost in such a formalism so there’s no reason no=
t to model things that way. All that C++ lacks is declarations that unpack =
tuples. Such a feature is hard to reconcile with the C legacy of declaratio=
ns supporting introduction of multiple names of the same type. But, we will=
probably see it added eventually.</div></div><br><div>However, that’=
s only syntactic sugar and there’s no bearing on machine architecture=
.. C++ is entirely machine independent and machine-specific extensions are o=
utside the scope of this discussion list.</div><div><br></div></body></html=
>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--Apple-Mail=_01E0F6CE-0D6A-4A50-816A-A34A87DB272E--
.
Author: Patrick Michael Niedzielski <patrickniedzielski@gmail.com>
Date: Tue, 10 Jun 2014 03:18:56 +0000
Raw View
--=-tKnwKTVkhjjDXHj+zXTL
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On mar, 2014-06-10 at 10:43 +0800, David Krauss wrote:
> Other CPUs do support multiple returns, at the hardware level. How do the=
y not? Can you name a single problem on a single architecture? On x64 speci=
fically?
I know you're having trouble following the link given for some reason,
but I'm relatively sure this talk (which I found through that link),
describes what he means by "having hardware support" for multiple
returns: <https://www.youtube.com/watch?v=3DQGw-cy0ylCc>. I can't say for
sure, because I'm still watching it right now, but from the description,
this seems to be it.
> You asked for existing practice and literature. If extending the language=
is part of your homework assignment, so be it, but again you need to state=
what difference needs to be made.
Why was this "homework assignment" comment was necessary? Be civil.
The past few emails you've sent in this thread have not come off as
civil.
Ivan:
How necessary do you think the syntactic extensions are? Ignoring, for
a second, the VARRESULTS functionality, do you think that this could
effectively be implemented without any changes to syntax, as in:
std::tuple<A, B, C> foo(D d, E e);
with each element of the tuple being able to be mapped to your return
values? For a compiler targeting your architecture, is there anything
that prevents the optimizer from decomposing the std::tuple into
multiple, in-hardware return values? I apologize, I'm still fuzzy on
what your hardware support for multiple return values means. But what
cases could not be covered by this solution, which doesn't need any
language changes?
The VARRESULTS functionality may be more problematic. Let's say:
/* ... */ bar();
returns a variable number of return values. Because the number of
return values can vary at runtime, the return type of foo cannot be
deduced at compile time. Thus,
auto i =3D bar(); // what is decltype(i)? we don't know
So we definitely need something more complicated than something this
simple. You may want to look into the recent proposal N4025 on classes
whose sizes can only be figured out at runtime. If foo() returns a type
of this sort, it could potentially be able to apply a similar
optimization as what I described above. Someone else here may be able
to disprove me on that.
Cheers,
Patrick
--=-tKnwKTVkhjjDXHj+zXTL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCgAGBQJTlnkhAAoJEJ5dAi8Pze/mnHQP/j0evwf0P4LEkwcTF/+ZNMmb
egEwTkH1rHwKl68RaXS7qCVT8eiou0KFHSOyqGoDDwHuM6ydn8lD/LGe900gKE5k
nb4pIj5rHo4MFPfa7NaM1EQ93oAcqjsvXJBywsHtf87IZfGOOCJ+olIiNfehsd78
n37e4FaFy9YWaVccxtV0wkyP1tS1CMMpb+MHKgf2sM+CGoKxFZdOw6x/Be1UMrxH
jZnLpefXAGNCKsAMg6KJEVz6oyYfVlBPRnhSVCprWW5j4i16syJmZ/kZZBTI5Gxn
3fKWKN8MGCEqJ3bmdWpVPG47dlbDshJqxMo/2E6tjtEK6S44f1TufHFQuywWeMQk
KRG2mpLTStk/VgOsLbm/hIh3srppezMWzMU2Ch6vqQTa3RNiQSXgqcc5B7dy7qqp
SFYaOlKLzDwwiuC7ydSohyMUjwVq8PRihvZ99WMd680kLisRE/ig0GrcMbrMxZTX
YhkoLX+T6NKxhqEptwaOidbCBG69DlOs5uJvLGMAprWIlLifu42AeEbjRJ6b9Zdz
sREjlyyGqCMJlxBbBl+x9jRHZS/taixXUMd7aIhb3qcmOo4KMa+764LiHJHXxEX8
ZGuIi5/f2I4ZW5WdcvrxJm2J6PnscHQC9g/xahhHgsM96R3//LiXjXzy8wR4zu2m
DaZvXwlnk5u3qUVAcwaX
=OqUV
-----END PGP SIGNATURE-----
--=-tKnwKTVkhjjDXHj+zXTL--
.
Author: Ivan Godard <ivan@MillComputing.com>
Date: Mon, 09 Jun 2014 21:21:48 -0700
Raw View
This is a multi-part message in MIME format.
--------------050305030108000106000802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 6/9/2014 7:43 PM, David Krauss wrote:
>
> On 2014--06--10, at 10:29 AM, Ivan Godard <ivan@MillComputing.com
> <mailto:ivan@MillComputing.com>> wrote:
>
>> We know why other CPUs do not have hardware support
>
> Other CPUs /do/ support multiple returns, at the hardware level. How
> do they not? Can you name a single problem on a single architecture?
> On x64 specifically?
>
With a few historical exceptions, other CPUs do not have a call
operation at all; they have a branch-and-link. On a Mill "f(a,b,c)" is
one hardware operation, total. There is neither preamble in the caller
other than the evaluation of the argument expressions, nor postamble
within the callee. The call operation saves all state, exits the current
frame and enters the new one, and passes all the arguments, in hardware,
in one clock. Yes, it's a CISC.
>> , but that's not the issue: right or wrong, we do have such support.
>> The question is how to make it naturally available as an extension of
>> C++.
>
> You asked for existing practice and literature. If extending the
> language is part of your homework assignment, so be it, but again you
> need to state what difference needs to be made.
I wish to inquire for suggestions or current and/or historic language
practice in support of functions returning more than one by-value
result. The notation should be convenient, intuitive and not convoluted
or unaesthetic, nor introduce superfluous variables.
If possible.
>
>> And yes, with sufficient analysis the compiler may bbe able to figure
>> out in some (many?) cases that a regular C++ single-valued function
>> can use the hardware operation, but that too is not the issue: we are
>> looking for a language extension by which the programmer can state
>> his intention that the function has some specific number of results
>> other than zero or one, whether or not the compiler could figure it out.
>>
>> Without requiring bogus dummy class types, or detecting that a
>> reference type is really not a reference type, or other kludgery.
>
> If you dig into implementations of other multiple-return languages
> such as Python, Haskell, ML, etc, you will find that multiple return
> values are always implemented as single values of tuple type. Nothing
> is lost in such a formalism so there's no reason not to model things
> that way. All that C++ lacks is declarations that unpack tuples. Such
> a feature is hard to reconcile with the C legacy of declarations
> supporting introduction of multiple names of the same type. But, we
> will probably see it added eventually.
I mentioned that approach as a possible notation. However, it is
ambiguous, because tuples are first class objects, so it is not obvious
whether the function is to return one tuple-type object, or several
by-value values. The difference is most evident when one of the tuple
components has neither copy nor move constructors.
> However, that's only syntactic sugar and there's no bearing on machine
> architecture. C++ is entirely machine independent
Well, there are those that say it incorporates a PDP-11. I've programmed
PDP-11s, and I will say the C part of C++ looks remarkable familiar.
> and machine-specific extensions are outside the scope of this
> discussion list.
>
That's a reasonable answer, thank you. Can you suggest a forum which
might be interested in such discussion?
Ivan
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/4g3NYpKwQX0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--
---
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/.
--------------050305030108000106000802
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 6/9/2014 7:43 PM, David Krauss
wrote:<br>
</div>
<blockquote
cite="mid:9E77EA8A-02F9-4AF8-B1A2-B1240499155F@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On 2014–06–10, at 10:29 AM, Ivan Godard <<a
moz-do-not-send="true" href="mailto:ivan@MillComputing.com">ivan@MillComputing.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"> We know why other CPUs
do not have hardware support</div>
</blockquote>
<div><br>
</div>
<div>Other CPUs <i>do</i> support multiple returns, at the
hardware level. How do they not? Can you name a single problem
on a single architecture? On x64 specifically?</div>
<br>
</div>
</blockquote>
With a few historical exceptions, other CPUs do not have a call
operation at all; they have a branch-and-link. On a Mill "f(a,b,c)"
is one hardware operation, total. There is neither preamble in the
caller other than the evaluation of the argument expressions, nor
postamble within the callee. The call operation saves all state,
exits the current frame and enters the new one, and passes all the
arguments, in hardware, in one clock. Yes, it's a CISC.<br>
<br>
<blockquote
cite="mid:9E77EA8A-02F9-4AF8-B1A2-B1240499155F@gmail.com"
type="cite">
<div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">, but that's not the
issue: right or wrong, we do have such support. The question
is how to make it naturally available as an extension of
C++.<br>
</div>
</blockquote>
<div><br>
</div>
<div>You asked for existing practice and literature. If
extending the language is part of your homework assignment, so
be it, but again you need to state what difference needs to be
made.</div>
</div>
</blockquote>
I wish to inquire for suggestions or current and/or historic
language practice in support of functions returning more than one
by-value result. The notation should be convenient, intuitive and
not convoluted or unaesthetic, nor introduce superfluous variables.<br>
<br>
If possible.<br>
<br>
<blockquote
cite="mid:9E77EA8A-02F9-4AF8-B1A2-B1240499155F@gmail.com"
type="cite">
<div><br>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">And yes, with sufficient
analysis the compiler may bbe able to figure out in some
(many?) cases that a regular C++ single-valued function can
use the hardware operation, but that too is not the issue:
we are looking for a language extension by which the
programmer can state his intention that the function has
some specific number of results other than zero or one,
whether or not the compiler could figure it out.<br>
<br>
Without requiring bogus dummy class types, or detecting that
a reference type is really not a reference type, or other
kludgery.<br>
</div>
</blockquote>
<div><br>
</div>
<div>If you dig into implementations of other multiple-return
languages such as Python, Haskell, ML, etc, you will find that
multiple return values are always implemented as single values
of tuple type. Nothing is lost in such a formalism so there’s
no reason not to model things that way. All that C++ lacks is
declarations that unpack tuples. Such a feature is hard to
reconcile with the C legacy of declarations supporting
introduction of multiple names of the same type. But, we will
probably see it added eventually.</div>
</div>
</blockquote>
I mentioned that approach as a possible notation. However, it is
ambiguous, because tuples are first class objects, so it is not
obvious whether the function is to return one tuple-type object, or
several by-value values. The difference is most evident when one of
the tuple components has neither copy nor move constructors.<br>
<blockquote
cite="mid:9E77EA8A-02F9-4AF8-B1A2-B1240499155F@gmail.com"
type="cite">
<div>However, that’s only syntactic sugar and there’s no bearing
on machine architecture. C++ is entirely machine independent </div>
</blockquote>
Well, there are those that say it incorporates a PDP-11. I've
programmed PDP-11s, and I will say the C part of C++ looks
remarkable familiar.<br>
<blockquote
cite="mid:9E77EA8A-02F9-4AF8-B1A2-B1240499155F@gmail.com"
type="cite">
<div>and machine-specific extensions are outside the scope of this
discussion list.</div>
<div><br>
</div>
</blockquote>
That's a reasonable answer, thank you. Can you suggest a forum which
might be interested in such discussion?<br>
<br>
Ivan<br>
<blockquote
cite="mid:9E77EA8A-02F9-4AF8-B1A2-B1240499155F@gmail.com"
type="cite">
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in
the Google Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a moz-do-not-send="true"
href="https://groups.google.com/a/isocpp.org/d/topic/std-proposals/4g3NYpKwQX0/unsubscribe">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/4g3NYpKwQX0/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email
to <a moz-do-not-send="true"
href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send="true"
href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send="true"
href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------050305030108000106000802--
.
Author: Ivan Godard <ivan@MillComputing.com>
Date: Mon, 09 Jun 2014 21:26:47 -0700
Raw View
Ah - that's the company security interface. You have been blocked
because your ISP or address range is a known source of spam or attack
vectors. You might check your system for viruses, or consider using a
different address. I'll let the site administrator know that you have
been blocked.
On 6/9/2014 7:32 PM, David Krauss wrote:
> Apparently I have been blocked by "project honey pot."
>
> You might consider an established host like GitHub.
>
>
> On 2014-06-10, at 10:23 AM, Ivan Godard <ivan@MillComputing.com> wrote:
>
>> Odd. Works for me, and it's a public site.
>>
>>
>> On 6/9/2014 6:50 PM, David Krauss wrote:
>>> On 2014-06-10, at 9:49 AM, ivan@ootbcomp.com wrote:
>>>
>>>> http://millcomputing.com/docs.
>>> 403 forbidden error.
>>>
>> --
>>
>> --- 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/.
--
---
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/.
.
Author: Ivan Godard <ivan@MillComputing.com>
Date: Mon, 09 Jun 2014 21:51:54 -0700
Raw View
On 6/9/2014 8:18 PM, Patrick Michael Niedzielski wrote:
> On mar, 2014-06-10 at 10:43 +0800, David Krauss wrote:
>> Other CPUs do support multiple returns, at the hardware level. How do they not? Can you name a single problem on a single architecture? On x64 specifically?
> I know you're having trouble following the link given for some reason,
> but I'm relatively sure this talk (which I found through that link),
> describes what he means by "having hardware support" for multiple
> returns: <https://www.youtube.com/watch?v=QGw-cy0ylCc>. I can't say for
> sure, because I'm still watching it right now, but from the description,
> this seems to be it.
Yes, that's the right talk.
>> You asked for existing practice and literature. If extending the language is part of your homework assignment, so be it, but again you need to state what difference needs to be made.
> Why was this "homework assignment" comment was necessary? Be civil.
> The past few emails you've sent in this thread have not come off
> civil.
>
>
> Ivan:
>
> How necessary do you think the syntactic extensions are? Ignoring, for
> a second, the VARRESULTS functionality, do you think that this could
> effectively be implemented without any changes to syntax, as in:
>
> std::tuple<A, B, C> foo(D d, E e);
Yes, that's a well-known solution. The problem is that it forces the
introduction of dummy variables (A/B/C). Not only is this inelegant (and
inefficient absent some heroics in the compiler) but there are problems
when the return component type(s) lack copy constructors.
Consider a function F with two scalar results, and a function G
accepting two arguments of the scalar type, where the intent is that the
results of F will be the arguments of G - in the opposite order. I was
hoping for something like:
G([lab:f()] lab$1, lab$0)
rather than the armwaving required to use tuples (note that I am very
much not proposing that syntax; my purpose here is to gather suggestions
for the syntax.
> with each element of the tuple being able to be mapped to your return
> values? For a compiler targeting your architecture, is there anything
> that prevents the optimizer from decomposing the std::tuple into
> multiple, in-hardware return values?
Not that I know of, unless the function is bound at link time and not
visible to the optimizer. In that case the distinction between returning
a tuple-type object and returning multiple values becomes ambiguous.
This problem is present whenever the optimizer is proposed to finesse
imputed types that don't actually exist in the type system. I'm hoping
to actually extend the type system for function types to include genuine
multi-result types. We expect to add whatever extension we come up with
to clang and gcc; this is not an academic exercise.
> I apologize, I'm still fuzzy on
> what your hardware support for multiple return values means. But what
> cases could not be covered by this solution, which doesn't need any
> language changes?
It is unclear to me that the tuple solution works when the result
component types lack copy constructors.
> The VARRESULTS functionality may be more problematic. Let's say:
>
> /* ... */ bar();
>
> returns a variable number of return values. Because the number of
> return values can vary at runtime, the return type of foo cannot be
> deduced at compile time. Thus,
>
> auto i = bar(); // what is decltype(i)? we don't know
>
> So we definitely need something more complicated than something this
> simple. You may want to look into the recent proposal N4025 on classes
> whose sizes can only be figured out at runtime. If foo() returns a type
> of this sort, it could potentially be able to apply a similar
> optimization as what I described above. Someone else here may be able
> to disprove me on that.
That sounds promising. Please forgive me, I am not part of the language
community and I don't know where I would find N4025; the first few pages
of Google yield nothing promising. Can you give me a pointer?
Thank you.
Ivan
--
---
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/.
.
Author: Thomas Braxton <kde.braxton@gmail.com>
Date: Mon, 9 Jun 2014 23:57:35 -0500
Raw View
--047d7b5d83918930c104fb742a98
Content-Type: text/plain; charset=UTF-8
On Mon, Jun 9, 2014 at 11:51 PM, Ivan Godard <ivan@millcomputing.com> wrote:
> N4025
https://isocpp.org/files/papers/n4025.pdf
--
---
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/.
--047d7b5d83918930c104fb742a98
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Mon, Jun 9, 2014 at 11:51 PM, Ivan Godard <span dir=3D"ltr"><<a href=
=3D"mailto:ivan@millcomputing.com" target=3D"_blank">ivan@millcomputing.com=
</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">N4025</blockquote></div><br><a href=3D"https://isocpp.org/=
files/papers/n4025.pdf">https://isocpp.org/files/papers/n4025.pdf</a><br>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--047d7b5d83918930c104fb742a98--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 10 Jun 2014 13:01:41 +0800
Raw View
--Apple-Mail=_A3E11789-622E-454A-889C-78EBE53F921C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-06-10, at 12:21 PM, Ivan Godard <ivan@MillComputing.com> wrote:
>=20
> On 6/9/2014 7:43 PM, David Krauss wrote:
>>=20
>> On 2014-06-10, at 10:29 AM, Ivan Godard <ivan@MillComputing.com> wrote:
>>=20
>>> We know why other CPUs do not have hardware support
>>=20
>> Other CPUs do support multiple returns, at the hardware level. How do th=
ey not? Can you name a single problem on a single architecture? On x64 spec=
ifically?
>>=20
> With a few historical exceptions, other CPUs do not have a call operation=
at all; they have a branch-and-link. On a Mill "f(a,b,c)" is one hardware =
operation, total. There is neither preamble in the caller other than the ev=
aluation of the argument expressions, nor postamble within the callee. The =
call operation saves all state, exits the current frame and enters the new =
one, and passes all the arguments, in hardware, in one clock. Yes, it's a C=
ISC.
You've changed the topic from returns to calls, but your answer still revea=
ls the truth: current architectures do not have function return operations =
at all, they have branch-to-link (and perhaps load some registers) operatio=
ns. Whatever registers aren't overwritten by such an instruction are eligib=
le to return data back to the caller.
The entire notion of subroutines is a higher-level construct which helps to=
organize programs.
For what it's worth, the notion of instructions is also somewhat arbitrary.=
As a CISC instruction is decoded you could call its constituent encodings =
as instructions instead. Or, you could consider the sequence of RISC instru=
ctions accomplishing a function call to be one instruction. If you squint h=
ard enough, then all the ISAs look the same, and they can all be represente=
d with something like LLVM IR.
> I wish to inquire for suggestions or current and/or historic language pra=
ctice in support of functions returning more than one by-value result. The =
notation should be convenient, intuitive and not convoluted or unaesthetic,=
nor introduce superfluous variables.
>=20
> If possible.
Those criteria are subjective. If you're serious about solving the problem,=
I urge you to consider the solution used by essentially all functional and=
procedural languages, which is to pack the multiple values into one tuple.
Data-types are also merely human constructs that help organize programs. Ev=
en if you invent another formalism that avoids calling the return values a =
tuple, it will still be equally valid to treat them as such, because the di=
fference is only in notation.
> I mentioned that approach as a possible notation. However, it is ambiguou=
s, because tuples are first class objects, so it is not obvious whether the=
function is to return one tuple-type object, or several by-value values. T=
he difference is most evident when one of the tuple components has neither =
copy nor move constructors.
Returning a value without a move or copy constructor is only partially supp=
orted by the language: the caller must bind the result to a local (non-memb=
er) reference. Personally I believe this limitation to be unjustified, and =
in the long run I'd like to see it eliminated. However, others believe diff=
erently.
As for current programming practice, it's safe to assume that return values=
are moveable or copyable.
Note that a partial workaround does exist, as piecewise construction of tup=
les. See std::piecewise_construct. This will accomplish a non-moveable obje=
ct inside a tuple, but all tuple elements must be constructed simultaneousl=
y.
As for whether you might want a new mechanism, as opposed to more sugary tu=
ples, are you prepared to sacrifice support or performance for programs tha=
t use tuples (or other aggregates) for this purpose?
>> However, that's only syntactic sugar and there's no bearing on machine a=
rchitecture. C++ is entirely machine independent
> Well, there are those that say it incorporates a PDP-11. I've programmed =
PDP-11s, and I will say the C part of C++ looks remarkable familiar.
>> and machine-specific extensions are outside the scope of this discussion=
list.
>>=20
> That's a reasonable answer, thank you. Can you suggest a forum which migh=
t be interested in such discussion?
The one on your website appears to be a natural choice. You should also dis=
cuss with your customers, who will be the first to write code using your ex=
tensions.
--=20
---=20
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 e=
mail 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-proposa=
ls/.
--Apple-Mail=_A3E11789-622E-454A-889C-78EBE53F921C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06–10, at 12:21 PM, Ivan Godard <<a href=3D"mailto:ivan@Mill=
Computing.com">ivan@MillComputing.com</a>> wrote:</div><br class=3D"Appl=
e-interchange-newline"><blockquote type=3D"cite">
=20
<meta content=3D"text/html; charset=3DISO-8859-1" http-equiv=3D"Content=
-Type">
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
<div class=3D"moz-cite-prefix">On 6/9/2014 7:43 PM, David Krauss
wrote:<br>
</div>
<blockquote cite=3D"mid:9E77EA8A-02F9-4AF8-B1A2-B1240499155F@gmail.com"=
type=3D"cite">
<meta http-equiv=3D"Content-Type" content=3D"text/html;
charset=3DISO-8859-1">
<br>
<div>
<div>On 2014–06–10, at 10:29 AM, Ivan Godard <<a moz=
-do-not-send=3D"true" href=3D"mailto:ivan@MillComputing.com">ivan@MillCompu=
ting.com</a>>
wrote:</div>
<br class=3D"Apple-interchange-newline">
<blockquote type=3D"cite">
<meta content=3D"text/html; charset=3DISO-8859-1" http-equiv=3D"C=
ontent-Type">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> We know why other CPUs
do not have hardware support</div>
</blockquote>
<div><br>
</div>
<div>Other CPUs <i>do</i> support multiple returns, at the
hardware level. How do they not? Can you name a single problem
on a single architecture? On x64 specifically?</div>
<br>
</div>
</blockquote>
With a few historical exceptions, other CPUs do not have a call
operation at all; they have a branch-and-link. On a Mill "f(a,b,c)"
is one hardware operation, total. There is neither preamble in the
caller other than the evaluation of the argument expressions, nor
postamble within the callee. The call operation saves all state,
exits the current frame and enters the new one, and passes all the
arguments, in hardware, in one clock. Yes, it's a CISC.<br></div></bloc=
kquote><div><br></div><div>You’ve changed the topic from returns to c=
alls, but your answer still reveals the truth: current architectures do not=
have function return operations at all, they have branch-to-link (and perh=
aps load some registers) operations. Whatever registers aren’t overwr=
itten by such an instruction are eligible to return data back to the caller=
..</div><div><br></div><div>The entire notion of subroutines is a higher-lev=
el construct which helps to organize programs.</div><div><br></div><div>For=
what it’s worth, the notion of instructions is also somewhat arbitra=
ry. As a CISC instruction is decoded you could call its constituent encodin=
gs as instructions instead. Or, you could consider the sequence of RISC ins=
tructions accomplishing a function call to be one instruction. If you squin=
t hard enough, then all the ISAs look the same, and they can all be represe=
nted with something like LLVM IR.</div><br><blockquote type=3D"cite"><div b=
gcolor=3D"#FFFFFF" text=3D"#000000">I wish to inquire for suggestions or cu=
rrent and/or historic
language practice in support of functions returning more than one
by-value result. The notation should be convenient, intuitive and
not convoluted or unaesthetic, nor introduce superfluous variables.<br>
<br>
If possible.<br></div></blockquote><div><br></div><div>Those criteria a=
re subjective. If you’re serious about solving the problem, I urge yo=
u to consider the solution used by essentially all functional and procedura=
l languages, which is to pack the multiple values into one tuple.</div><div=
><br></div><div>Data-types are also merely human constructs that help organ=
ize programs. Even if you invent another formalism that avoids calling the =
return values a tuple, it will still be equally valid to treat them as such=
, because the difference is only in notation.</div><br><blockquote type=3D"=
cite"><div bgcolor=3D"#FFFFFF" text=3D"#000000">I mentioned that approach a=
s a possible notation. However, it is
ambiguous, because tuples are first class objects, so it is not
obvious whether the function is to return one tuple-type object, or
several by-value values. The difference is most evident when one of
the tuple components has neither copy nor move constructors.<br></div><=
/blockquote><div><br></div><div>Returning a value without a move or copy co=
nstructor is only partially supported by the language: the caller must bind=
the result to a local (non-member) reference. Personally I believe this li=
mitation to be unjustified, and in the long run I’d like to see it el=
iminated. However, others believe differently.</div><div><br></div><div>As =
for current programming practice, it’s safe to assume that return val=
ues are moveable or copyable.</div><div><br></div><div>Note that a partial =
workaround does exist, as piecewise construction of tuples. See <font face=
=3D"Courier">std::piecewise_construct</font>. This will accomplish a non-mo=
veable object inside a tuple, but all tuple elements must be constructed si=
multaneously.</div><div><br></div><div>As for whether you might want a new =
mechanism, as opposed to more sugary tuples, are you prepared to sacrifice =
support or performance for programs that use tuples (or other aggregates) f=
or this purpose?</div><br><blockquote type=3D"cite"><div bgcolor=3D"#FFFFFF=
" text=3D"#000000">
<blockquote cite=3D"mid:9E77EA8A-02F9-4AF8-B1A2-B1240499155F@gmail.com"=
type=3D"cite">
<div>However, that’s only syntactic sugar and there’s no =
bearing
on machine architecture. C++ is entirely machine independent </div>
</blockquote>
Well, there are those that say it incorporates a PDP-11. I've
programmed PDP-11s, and I will say the C part of C++ looks
remarkable familiar.<br>
<blockquote cite=3D"mid:9E77EA8A-02F9-4AF8-B1A2-B1240499155F@gmail.com"=
type=3D"cite">
<div>and machine-specific extensions are outside the scope of this
discussion list.</div>
<div><br>
</div>
</blockquote>
That's a reasonable answer, thank you. Can you suggest a forum which
might be interested in such discussion?<br></div></blockquote><br></div=
><div>The one on your website appears to be a natural choice. You should al=
so discuss with your customers, who will be the first to write code using y=
our extensions.</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--Apple-Mail=_A3E11789-622E-454A-889C-78EBE53F921C--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 10 Jun 2014 13:20:24 +0800
Raw View
--Apple-Mail=_DDA06516-2207-4C68-BF91-5322B06FBA0C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-06-10, at 12:51 PM, Ivan Godard <ivan@MillComputing.com> wrote:
> Consider a function F with two scalar results, and a function G accepting=
two arguments of the scalar type, where the intent is that the results of =
F will be the arguments of G - in the opposite order. I was hoping for some=
thing like:
> G([lab:f()] lab$1, lab$0)
> rather than the armwaving required to use tuples (note that I am very muc=
h not proposing that syntax; my purpose here is to gather suggestions for t=
he syntax.
The only way for the C++ programmer to route values into functions is to pa=
ss them individually. Some languages support unpacking primitive tuples as =
arguments (and C++ only requires adding a wrapper function), but in your ex=
ample the programmer would still need to name the items individually.
However, programmer notation has no bearing on object code generation. If y=
our hardware has some distinct addresses for multiple return values, which =
need to be coded in a subsequent CALL instruction, then your code generator=
will need to detect the way data is being routed given intermediate-level =
program representation.
>> with each element of the tuple being able to be mapped to your return
>> values? For a compiler targeting your architecture, is there anything
>> that prevents the optimizer from decomposing the std::tuple into
>> multiple, in-hardware return values?
> Not that I know of, unless the function is bound at link time and not vis=
ible to the optimizer. In that case the distinction between returning a tup=
le-type object and returning multiple values becomes ambiguous. This proble=
m is present whenever the optimizer is proposed to finesse imputed types th=
at don't actually exist in the type system. I'm hoping to actually extend t=
he type system for function types to include genuine multi-result types. We=
expect to add whatever extension we come up with to clang and gcc; this is=
not an academic exercise.
The first task in a compiler port is to design an ABI, so I suggest you spe=
cify aggregate return values to go into multiple registers. Is there a reas=
on this wouldn't work as the general case? (And is there any other possible=
programmer intent in returning an aggregate type?)
>> I apologize, I'm still fuzzy on
>> what your hardware support for multiple return values means. But what
>> cases could not be covered by this solution, which doesn't need any
>> language changes?
> It is unclear to me that the tuple solution works when the result compone=
nt types lack copy constructors.
I've addressed this in my previous message. Also, you can define an extensi=
on to separately construct tuple items, and still have the result be an ABI=
-compatible tuple. In fact, I don't see why it can't be contained within a =
100% compatible library extension:
// Return a tuple of uninitialized storage.
template< typename ... t >
std::tuple< t ... > make_uninitialized_tuple();
// Initialize one tuple element.
/* All elements must be initialized before the tuple lifetime ends
(i.e. before return or any exception may be thrown). */
template< std::size_t n, typename tuple_type, typename ... construct_arg >
void initialize_tuple_element( tuple_type & t, construct_arg && ... a );
The exception safety is probably a deal-breaker, though.
--=20
---=20
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 e=
mail 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-proposa=
ls/.
--Apple-Mail=_DDA06516-2207-4C68-BF91-5322B06FBA0C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06–10, at 12:51 PM, Ivan Godard <<a href=3D"mailto:ivan@Mill=
Computing.com">ivan@MillComputing.com</a>> wrote:</div><br class=3D"Appl=
e-interchange-newline"><blockquote type=3D"cite">Consider a function F with=
two scalar results, and a function G accepting two arguments of the scalar=
type, where the intent is that the results of F will be the arguments of G=
- in the opposite order. I was hoping for something like:<br> =
&nb=
sp; G([lab:f()] lab$1,=
lab$0)<br>rather than the armwaving required to use tuples (note that I am=
very much not proposing that syntax; my purpose here is to gather suggesti=
ons for the syntax.<br></blockquote><div><br></div><div>The only way for th=
e C++ programmer to route values into functions is to pass them individuall=
y. Some languages support unpacking primitive tuples as arguments (and C++ =
only requires adding a wrapper function), but in your example the programme=
r would still need to name the items individually.</div><div><br></div><div=
>However, programmer notation has no bearing on object code generation. If =
your hardware has some distinct addresses for multiple return values, which=
need to be coded in a subsequent CALL instruction, then your code generato=
r will need to detect the way data is being routed given intermediate-level=
program representation.</div><div><br></div><blockquote type=3D"cite"><blo=
ckquote type=3D"cite">with each element of the tuple being able to be mappe=
d to your return<br>values? For a compiler targeting your architectur=
e, is there anything<br>that prevents the optimizer from decomposing the st=
d::tuple into<br>multiple, in-hardware return values?<br></blockquote>Not t=
hat I know of, unless the function is bound at link time and not visible to=
the optimizer. In that case the distinction between returning a tuple-type=
object and returning multiple values becomes ambiguous. This problem is pr=
esent whenever the optimizer is proposed to finesse imputed types that don'=
t actually exist in the type system. I'm hoping to actually extend the type=
system for function types to include genuine multi-result types. We expect=
to add whatever extension we come up with to clang and gcc; this is not an=
academic exercise.<br></blockquote><div><br></div><div>The first task in a=
compiler port is to design an ABI, so I suggest you specify aggregate retu=
rn values to go into multiple registers. Is there a reason this wouldn't wo=
rk as the general case? (And is there any other possible programmer intent =
in returning an aggregate type?)</div><br><blockquote type=3D"cite"><blockq=
uote type=3D"cite"> I apologize, I'm still fuzzy on<br>what your hard=
ware support for multiple return values means. But what<br>cases coul=
d not be covered by this solution, which doesn't need any<br>language chang=
es?<br></blockquote>It is unclear to me that the tuple solution works when =
the result component types lack copy constructors.<br></blockquote><div><br=
></div><div>I’ve addressed this in my previous message. Also, you can=
define an extension to separately construct tuple items, and still have th=
e result be an ABI-compatible tuple. In fact, I don’t see why it can&=
rsquo;t be contained within a 100% compatible library extension:</div><div>=
<br></div><div><font face=3D"Courier">// Return a tuple of uninitialized st=
orage.</font></div><div><font face=3D"Courier">template< typename ... t =
></font></div><div><font face=3D"Courier">std::tuple< t ... > make=
_uninitialized_tuple();</font></div><div><font face=3D"Courier"><br></font>=
</div><div><font face=3D"Courier">// Initialize one tuple element.</font></=
div><div><font face=3D"Courier">/* All elements must be initialized before =
the tuple lifetime ends</font></div><div><font face=3D"Courier"> (i.e.=
before return or any exception may be thrown). */</font></div><div><font f=
ace=3D"Courier">template< std::size_t n, typename tuple_type, typename .=
... construct_arg ></font></div><div><font face=3D"Courier">void initiali=
ze_tuple_element( tuple_type & t, construct_arg && ... a );</fo=
nt></div><div><br></div><div>The exception safety is probably a deal-breake=
r, though.</div></div><br></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--Apple-Mail=_DDA06516-2207-4C68-BF91-5322B06FBA0C--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 10 Jun 2014 13:35:40 +0800
Raw View
--Apple-Mail=_EA23E280-2F0E-4EF0-92A0-321ECC5AEE8D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-06-10, at 11:18 AM, Patrick Michael Niedzielski <patrickniedzielski=
@gmail.com> wrote:
> Why was this "homework assignment" comment was necessary? Be civil.
Homework is the only justification for ignoring a widely implemented soluti=
on for the sake of implementing something new.
There's no shame in doing homework, but insisting on inventing something fo=
r novelty's sake is Wrong. What we have here is a man in search of a soluti=
on in search of a problem. He doesn't know what his extension is yet, he ju=
st knows he wants some kind of an extension. C++ handles multiple returns e=
ssentially the same as any other language, but it's a "kludge" because it's=
not bespoke.
Presupposition that new solutions are needed is not the way an engineer sho=
uld think. Prototypes are built using the parts on hand, and no evidence ha=
s so far been presented that the parts do not fit. If we need more detail a=
bout multiple returns, it should be described within the immediate request =
and not left in the middle of an hours-long video series.
> The past few emails you've sent in this thread have not come off as
> civil.
The first post immediately raised red flags. The assertion that a new CPU a=
rchitecture is completely different from everything else is immediately sus=
picious, because after 60+ years of experimentation there are few completel=
y novel ideas. To communicate architectural details to a literate audience,=
it is expedient to reference literature. Following the YouTube link and ch=
ecking the website via archive.org reinforces my impression that the materi=
als, by intention or not, are geared to an illiterate audience of potential=
investors. This rubs me the wrong way.
Anyone with the experience to do what Ivan says he did, knows that multiple=
returns are commonplace in handwritten assembler for any conventional regi=
ster-based architecture. (Even more common for stack machines.) So the asse=
rtion that they're unsupported is just disingenuous. Even variable length r=
eturns are easily done with a call stack, and there is precedent for puttin=
g the stack in rename registers. This has nothing to do with C++, by the wa=
y.
> <https://www.youtube.com/watch?v=3DQGw-cy0ylCc>
"DSP code, all those loops are software pipelined, and software pipelines h=
ave unbounded ILP."
Even DSP filters often have dependencies over loop iterations.
"Rather few general-purpose loops can be software pipelined. They contain r=
eally nasty things like function calls, that are full of control."
No, they cannot be pipelined because of Amdahl's law: you can only go so fa=
r before hitting a dependent computation.
"Any of you who do do chip design know I'm lying through my teeth"
Well, I have done a smidgen of physical circuit design, and I'd like to see=
what magic network wiring can be a game-changer.
--
I'll stop now and get back to work, but civility is not the best thing when=
it comes to scammers. Big dreams are well and good, but asking money for r=
esearch that requires no materials, misrepresenting the degree of originali=
ty, is unjustified. Claiming that additional language support is needed whe=
n its not, and such requirement of extensions being a historical reason for=
failure of projects just like this, is disingenuous. There's no problem wi=
th Ivan pursuing personal projects, but the connections drawn in messages h=
ere between C++ notation and machine code suggest a lack of the familiarity=
with modern compilers that is essential to ISA design. Acting like a seaso=
ned pro with a comp-arch business plan, but without familiarity with the so=
ftware development stack, is fraud.
TL;DR: If he wants to succeed, he will avoid language extensions and use pu=
re LLVM IR as source. If the project is for real, it can take my flak. If i=
t's not, I'm doing skeptics a valuable service with public criticism.
--=20
---=20
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 e=
mail 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-proposa=
ls/.
--Apple-Mail=_EA23E280-2F0E-4EF0-92A0-321ECC5AEE8D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06–10, at 11:18 AM, Patrick Michael Niedzielski <<a href=3D"=
mailto:patrickniedzielski@gmail.com">patrickniedzielski@gmail.com</a>> w=
rote:</div><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite=
">Why was this "homework assignment" comment was necessary? Be civil.=
<br></blockquote><div><br></div><div>Homework is the only justification for=
ignoring a widely implemented solution for the sake of implementing someth=
ing new.</div><div><br></div><div>There’s no shame in doing homework,=
but insisting on inventing something for novelty’s sake is Wrong. Wh=
at we have here is a man in search of a solution in search of a problem. He=
doesn’t know what his extension is yet, he just knows he wants some =
kind of an extension. C++ handles multiple returns essentially the same as =
any other language, but it’s a “kludge” because it’=
s not bespoke.</div><div><br></div><div>Presupposition that new solutions a=
re needed is not the way an engineer should think. Prototypes are built usi=
ng the parts on hand, and no evidence has so far been presented that the pa=
rts do not fit. If we need more detail about multiple returns, it should be=
described within the immediate request and not left in the middle of an ho=
urs-long video series.</div><br><blockquote type=3D"cite">The past few emai=
ls you've sent in this thread have not come off as<br>civil.<br></blockquot=
e><div><br></div><div>The first post immediately raised red flags. The asse=
rtion that a new CPU architecture is completely different from everything e=
lse is immediately suspicious, because after 60+ years of experimentation t=
here are few completely novel ideas. To communicate architectural details t=
o a literate audience, it is expedient to reference literature. Following t=
he YouTube link and checking the website via <a href=3D"http://archive.org"=
>archive.org</a> reinforces my impression that the materials, by intention =
or not, are geared to an illiterate audience of potential investors. This r=
ubs me the wrong way.</div><div><br></div><div>Anyone with the experience t=
o do what Ivan says he did, knows that multiple returns are commonplace in =
handwritten assembler for any conventional register-based architecture. (Ev=
en more common for stack machines.) So the assertion that they’re uns=
upported is just disingenuous. Even variable length returns are easily done=
with a call stack, and there is precedent for putting the stack in rename =
registers. This has nothing to do with C++, by the way.</div><div><br></div=
><div><blockquote type=3D"cite"><<a href=3D"https://www.youtube.com/watc=
h?v=3DQGw-cy0ylCc">https://www.youtube.com/watch?v=3DQGw-cy0ylCc</a>><br=
></blockquote></div><div><br></div><div>“DSP code, all those loops ar=
e software pipelined, and software pipelines have unbounded ILP.”</di=
v><div><br></div><div>Even DSP filters often have dependencies over loop it=
erations.</div><div><br></div><div>“Rather few general-purpose loops =
can be software pipelined. They contain really nasty things like function c=
alls, that are full of control."</div><div><br></div>No, they cannot be pip=
elined because of Amdahl’s law: you can only go so far before hitting=
a dependent computation.</div><div><br></div><div>“Any of you who do=
do chip design know I’m lying through my teeth”</div><div><br>=
</div><div>Well, I have done a smidgen of physical circuit design, and I&rs=
quo;d like to see what magic network wiring can be a game-changer.</div><di=
v><br></div><div>—</div><div><br></div><div>I’ll stop now and g=
et back to work, but civility is not the best thing when it comes to scamme=
rs. Big dreams are well and good, but asking money for research that requir=
es no materials, misrepresenting the degree of originality, is unjustified.=
Claiming that additional language support is needed when its not, and such=
requirement of extensions being a historical reason for <i>failure</i>&nbs=
p;of projects just like this, is disingenuous. There’s no problem wit=
h Ivan pursuing personal projects, but the connections drawn in messages he=
re between C++ notation and machine code suggest a lack of the familiarity =
with modern compilers that is essential to ISA design. Acting like a season=
ed pro with a comp-arch business plan, but without familiarity with the sof=
tware development stack, is fraud.</div><div><br></div><div>TL;DR: If he wa=
nts to succeed, he will avoid language extensions and use pure LLVM IR as s=
ource. If the project is for real, it can take my flak. If it’s not, =
I’m doing skeptics a valuable service with public criticism.</div><di=
v><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--Apple-Mail=_EA23E280-2F0E-4EF0-92A0-321ECC5AEE8D--
.
Author: Ivan Godard <ivan@MillComputing.com>
Date: Mon, 09 Jun 2014 22:56:29 -0700
Raw View
This is a multi-part message in MIME format.
--------------090304000509030604010600
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 6/9/2014 10:01 PM, David Krauss wrote:
>
> On 2014--06--10, at 12:21 PM, Ivan Godard <ivan@MillComputing.com
> <mailto:ivan@MillComputing.com>> wrote:
>
>>
>> On 6/9/2014 7:43 PM, David Krauss wrote:
>>>
>>> On 2014--06--10, at 10:29 AM, Ivan Godard <ivan@MillComputing.com
>>> <mailto:ivan@MillComputing.com>> wrote:
>>>
>>>> We know why other CPUs do not have hardware support
>>>
>>> Other CPUs /do/ support multiple returns, at the hardware level. How
>>> do they not? Can you name a single problem on a single architecture?
>>> On x64 specifically?
>>>
>> With a few historical exceptions, other CPUs do not have a call
>> operation at all; they have a branch-and-link. On a Mill "f(a,b,c)"
>> is one hardware operation, total. There is neither preamble in the
>> caller other than the evaluation of the argument expressions, nor
>> postamble within the callee. The call operation saves all state,
>> exits the current frame and enters the new one, and passes all the
>> arguments, in hardware, in one clock. Yes, it's a CISC.
>
> You've changed the topic from returns to calls, but your answer still
> reveals the truth: current architectures do not have function return
> operations at all, they have branch-to-link (and perhaps load some
> registers) operations. Whatever registers aren't overwritten by such
> an instruction are eligible to return data back to the caller.
>
The Mill is a new architecture. The return operation (also a hardware
primitive) unwinds what the hardware call operation does.The Mill has no
general registers, and values are SSA.
> The entire notion of subroutines is a higher-level construct which
> helps to organize programs.
>
And it is up to the hardware designer to decide how close the hardware
primitive should map to the language primitive. Yes, a subroutine is a
construct to organize programs, but so is an add. At root all the
hardware you need is two bricks and a roll of toilet paper; all else
beyond that is cost-benefit. In the case of the Mill, our call and
return ops are significantly higher level than is common, and
multi-return falls out of the design. We find multi-return useful in all
sorts of odd places, were it not so clumsy to use from conventional
languages that lack OUT parameters.
> For what it's worth, the notion of instructions is also somewhat
> arbitrary. As a CISC instruction is decoded you could call its
> constituent encodings as instructions instead. Or, you could consider
> the sequence of RISC instructions accomplishing a function call to be
> one instruction. If you squint hard enough, then all the ISAs look the
> same, and they can all be represented with something like LLVM IR.
>
"Instruction" is not an arbitrary notion from the viewpoint of a
decoder/dispatcher, and "operation" is not an arbitrary notion from the
view of a functional unit like an ALU. We are in the process of porting
our toolchain to LLVM, and have found that the IR makes some really
egregious assumptions about the character of the eventual target. For
example, it assumes that pointers are integers.
>> I wish to inquire for suggestions or current and/or historic language
>> practice in support of functions returning more than one by-value
>> result. The notation should be convenient, intuitive and not
>> convoluted or unaesthetic, nor introduce superfluous variables.
>>
>> If possible.
>
> Those criteria are subjective. If you're serious about solving the
> problem, I urge you to consider the solution used by essentially all
> functional and procedural languages, which is to pack the multiple
> values into one tuple.
>
I am looking for better, or ideas leading toward better.
> Data-types are also merely human constructs that help organize
> programs. Even if you invent another formalism that avoids calling the
> return values a tuple, it will still be equally valid to treat them as
> such, because the difference is only in notation.
>
Are you sure of that? Consider a function returning a value of type T,
and a function returning a single-component tuple whose component is of
type T. Is there truly no T for which the behavior of the two is
different? I had thought there was.
>> I mentioned that approach as a possible notation. However, it is
>> ambiguous, because tuples are first class objects, so it is not
>> obvious whether the function is to return one tuple-type object, or
>> several by-value values. The difference is most evident when one of
>> the tuple components has neither copy nor move constructors.
>
> Returning a value without a move or copy constructor is only partially
> supported by the language: the caller must bind the result to a local
> (non-member) reference. Personally I believe this limitation to be
> unjustified, and in the long run I'd like to see it eliminated.
> However, others believe differently.
I would support you.
>
> As for current programming practice, it's safe to assume that return
> values are moveable or copyable.
>
> Note that a partial workaround does exist, as piecewise construction
> of tuples. See std::piecewise_construct. This will accomplish a
> non-moveable object inside a tuple, but all tuple elements must be
> constructed simultaneously.
>
Thank you; I'll treat that as a homework assignment.
> As for whether you might want a new mechanism, as opposed to more
> sugary tuples, are you prepared to sacrifice support or performance
> for programs that use tuples (or other aggregates) for this purpose?
>
The intent is that the extensions (this case, and others in process,
which I may bring here) are proprietary, although if clang/gcc accepts
them as contributions then they will be available to others. As for
sacrificing performance, we are considering alternatives precisely
because the tuple approach so badly blows out the hardware performance.
Consider a function with two int results, and an expression that wants
the sum of them. On a Mill, using assembly language, that is two
hardware operations - a call and an add. I have tried the corresponding
tuple code in various compilation systems and targets available to me,
and have been unable to get below 12 operations and some were over
fifty. Your mileage may vary; if you have a platform that gets it to two
then please post the source code used in the test, the target machine,
and the compiler version and settings.
>>> However, that's only syntactic sugar and there's no bearing on
>>> machine architecture. C++ is entirely machine independent
>> Well, there are those that say it incorporates a PDP-11. I've
>> programmed PDP-11s, and I will say the C part of C++ looks remarkable
>> familiar.
>>> and machine-specific extensions are outside the scope of this
>>> discussion list.
>>>
>> That's a reasonable answer, thank you. Can you suggest a forum which
>> might be interested in such discussion?
>
> The one on your website appears to be a natural choice. You should
> also discuss with your customers, who will be the first to write code
> using your extensions.
>
As might be expected for a hardware company, our forums are mostly
populated by those interested in architecture rather than languages.
Hence I have come here.
I am moderately competent in language design - I was in on the revision
of Algol68 and my name is in the Revised Report; I was on the Green team
that won the Ada competition; I am the designer of the Mary family of
languages, which I'm sure you have never heard of; have had my fingers
in other languages to a lesser extent; and have done nearly a dozen
compilers for a variety of languages and targets, one still in active
use today forty years after I wrote it. However, I remain happy to seek
the assistance of others; it is not possible to know everything in a
field, and there is wisdom in crowds. I thank you for your time.
Ivan
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/4g3NYpKwQX0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--
---
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/.
--------------090304000509030604010600
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 6/9/2014 10:01 PM, David Krauss
wrote:<br>
</div>
<blockquote
cite="mid:1FE9C0E0-B191-4706-8EA3-054722B506B1@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On 2014–06–10, at 12:21 PM, Ivan Godard <<a
moz-do-not-send="true" href="mailto:ivan@MillComputing.com">ivan@MillComputing.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"> <br>
<div class="moz-cite-prefix">On 6/9/2014 7:43 PM, David
Krauss wrote:<br>
</div>
<blockquote
cite="mid:9E77EA8A-02F9-4AF8-B1A2-B1240499155F@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On 2014–06–10, at 10:29 AM, Ivan Godard <<a
moz-do-not-send="true"
href="mailto:ivan@MillComputing.com">ivan@MillComputing.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"> We know why
other CPUs do not have hardware support</div>
</blockquote>
<div><br>
</div>
<div>Other CPUs <i>do</i> support multiple returns, at
the hardware level. How do they not? Can you name a
single problem on a single architecture? On x64
specifically?</div>
<br>
</div>
</blockquote>
With a few historical exceptions, other CPUs do not have a
call operation at all; they have a branch-and-link. On a
Mill "f(a,b,c)" is one hardware operation, total. There is
neither preamble in the caller other than the evaluation of
the argument expressions, nor postamble within the callee.
The call operation saves all state, exits the current frame
and enters the new one, and passes all the arguments, in
hardware, in one clock. Yes, it's a CISC.<br>
</div>
</blockquote>
<div><br>
</div>
<div>You’ve changed the topic from returns to calls, but your
answer still reveals the truth: current architectures do not
have function return operations at all, they have
branch-to-link (and perhaps load some registers) operations.
Whatever registers aren’t overwritten by such an instruction
are eligible to return data back to the caller.</div>
<div><br>
</div>
</div>
</blockquote>
The Mill is a new architecture. The return operation (also a
hardware primitive) unwinds what the hardware call operation
does.The Mill has no general registers, and values are SSA.<br>
<blockquote
cite="mid:1FE9C0E0-B191-4706-8EA3-054722B506B1@gmail.com"
type="cite">
<div>
<div>The entire notion of subroutines is a higher-level
construct which helps to organize programs.</div>
<div><br>
</div>
</div>
</blockquote>
And it is up to the hardware designer to decide how close the
hardware primitive should map to the language primitive. Yes, a
subroutine is a construct to organize programs, but so is an add. At
root all the hardware you need is two bricks and a roll of toilet
paper; all else beyond that is cost-benefit. In the case of the
Mill, our call and return ops are significantly higher level than is
common, and multi-return falls out of the design. We find
multi-return useful in all sorts of odd places, were it not so
clumsy to use from conventional languages that lack OUT parameters.<br>
<br>
<blockquote
cite="mid:1FE9C0E0-B191-4706-8EA3-054722B506B1@gmail.com"
type="cite">
<div>
<div>For what it’s worth, the notion of instructions is also
somewhat arbitrary. As a CISC instruction is decoded you could
call its constituent encodings as instructions instead. Or,
you could consider the sequence of RISC instructions
accomplishing a function call to be one instruction. If you
squint hard enough, then all the ISAs look the same, and they
can all be represented with something like LLVM IR.</div>
<br>
</div>
</blockquote>
"Instruction" is not an arbitrary notion from the viewpoint of a
decoder/dispatcher, and "operation" is not an arbitrary notion from
the view of a functional unit like an ALU. We are in the process of
porting our toolchain to LLVM, and have found that the IR makes some
really egregious assumptions about the character of the eventual
target. For example, it assumes that pointers are integers.<br>
<blockquote
cite="mid:1FE9C0E0-B191-4706-8EA3-054722B506B1@gmail.com"
type="cite">
<div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">I wish to inquire for
suggestions or current and/or historic language practice in
support of functions returning more than one by-value
result. The notation should be convenient, intuitive and not
convoluted or unaesthetic, nor introduce superfluous
variables.<br>
<br>
If possible.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Those criteria are subjective. If you’re serious about
solving the problem, I urge you to consider the solution used
by essentially all functional and procedural languages, which
is to pack the multiple values into one tuple.</div>
<div><br>
</div>
</div>
</blockquote>
I am looking for better, or ideas leading toward better.<br>
<blockquote
cite="mid:1FE9C0E0-B191-4706-8EA3-054722B506B1@gmail.com"
type="cite">
<div>
<div>Data-types are also merely human constructs that help
organize programs. Even if you invent another formalism that
avoids calling the return values a tuple, it will still be
equally valid to treat them as such, because the difference is
only in notation.</div>
<br>
</div>
</blockquote>
Are you sure of that? Consider a function returning a value of type
T, and a function returning a single-component tuple whose component
is of type T. Is there truly no T for which the behavior of the two
is different? I had thought there was.<br>
<br>
<blockquote
cite="mid:1FE9C0E0-B191-4706-8EA3-054722B506B1@gmail.com"
type="cite">
<div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">I mentioned that
approach as a possible notation. However, it is ambiguous,
because tuples are first class objects, so it is not obvious
whether the function is to return one tuple-type object, or
several by-value values. The difference is most evident when
one of the tuple components has neither copy nor move
constructors.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Returning a value without a move or copy constructor is
only partially supported by the language: the caller must bind
the result to a local (non-member) reference. Personally I
believe this limitation to be unjustified, and in the long run
I’d like to see it eliminated. However, others believe
differently.</div>
</div>
</blockquote>
I would support you.<br>
<blockquote
cite="mid:1FE9C0E0-B191-4706-8EA3-054722B506B1@gmail.com"
type="cite">
<div>
<div><br>
</div>
<div>As for current programming practice, it’s safe to assume
that return values are moveable or copyable.</div>
<div><br>
</div>
<div>Note that a partial workaround does exist, as piecewise
construction of tuples. See <font face="Courier">std::piecewise_construct</font>.
This will accomplish a non-moveable object inside a tuple, but
all tuple elements must be constructed simultaneously.</div>
<div><br>
</div>
</div>
</blockquote>
Thank you; I'll treat that as a homework assignment.<br>
<blockquote
cite="mid:1FE9C0E0-B191-4706-8EA3-054722B506B1@gmail.com"
type="cite">
<div>
<div>As for whether you might want a new mechanism, as opposed
to more sugary tuples, are you prepared to sacrifice support
or performance for programs that use tuples (or other
aggregates) for this purpose?</div>
<br>
</div>
</blockquote>
The intent is that the extensions (this case, and others in process,
which I may bring here) are proprietary, although if clang/gcc
accepts them as contributions then they will be available to others.
As for sacrificing performance, we are considering alternatives
precisely because the tuple approach so badly blows out the hardware
performance.<br>
<br>
Consider a function with two int results, and an expression that
wants the sum of them. On a Mill, using assembly language, that is
two hardware operations - a call and an add. I have tried the
corresponding tuple code in various compilation systems and targets
available to me, and have been unable to get below 12 operations and
some were over fifty. Your mileage may vary; if you have a platform
that gets it to two then please post the source code used in the
test, the target machine, and the compiler version and settings.<br>
<br>
<blockquote
cite="mid:1FE9C0E0-B191-4706-8EA3-054722B506B1@gmail.com"
type="cite">
<div>
<blockquote type="cite">
<div bgcolor="#FFFFFF" text="#000000">
<blockquote
cite="mid:9E77EA8A-02F9-4AF8-B1A2-B1240499155F@gmail.com"
type="cite">
<div>However, that’s only syntactic sugar and there’s no
bearing on machine architecture. C++ is entirely machine
independent </div>
</blockquote>
Well, there are those that say it incorporates a PDP-11.
I've programmed PDP-11s, and I will say the C part of C++
looks remarkable familiar.<br>
<blockquote
cite="mid:9E77EA8A-02F9-4AF8-B1A2-B1240499155F@gmail.com"
type="cite">
<div>and machine-specific extensions are outside the scope
of this discussion list.</div>
<div><br>
</div>
</blockquote>
That's a reasonable answer, thank you. Can you suggest a
forum which might be interested in such discussion?<br>
</div>
</blockquote>
<br>
</div>
<div>The one on your website appears to be a natural choice. You
should also discuss with your customers, who will be the first
to write code using your extensions.</div>
<div><br>
</div>
</blockquote>
As might be expected for a hardware company, our forums are mostly
populated by those interested in architecture rather than languages.
Hence I have come here.<br>
<br>
I am moderately competent in language design - I was in on the
revision of Algol68 and my name is in the Revised Report; I was on
the Green team that won the Ada competition; I am the designer of
the Mary family of languages, which I'm sure you have never heard
of; have had my fingers in other languages to a lesser extent; and
have done nearly a dozen compilers for a variety of languages and
targets, one still in active use today forty years after I wrote it.
However, I remain happy to seek the assistance of others; it is not
possible to know everything in a field, and there is wisdom in
crowds. I thank you for your time.<br>
<br>
Ivan<br>
<blockquote
cite="mid:1FE9C0E0-B191-4706-8EA3-054722B506B1@gmail.com"
type="cite">
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in
the Google Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a moz-do-not-send="true"
href="https://groups.google.com/a/isocpp.org/d/topic/std-proposals/4g3NYpKwQX0/unsubscribe">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/4g3NYpKwQX0/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email
to <a moz-do-not-send="true"
href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send="true"
href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send="true"
href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------090304000509030604010600--
.
Author: Ivan Godard <ivan@MillComputing.com>
Date: Mon, 09 Jun 2014 23:12:50 -0700
Raw View
This is a multi-part message in MIME format.
--------------070709010408030009060802
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 6/9/2014 10:20 PM, David Krauss wrote:
>
> On 2014--06--10, at 12:51 PM, Ivan Godard <ivan@MillComputing.com
> <mailto:ivan@MillComputing.com>> wrote:
>
>> Consider a function F with two scalar results, and a function G
>> accepting two arguments of the scalar type, where the intent is that
>> the results of F will be the arguments of G - in the opposite order.
>> I was hoping for something like:
>> G([lab:f()] lab$1, lab$0)
>> rather than the armwaving required to use tuples (note that I am very
>> much not proposing that syntax; my purpose here is to gather
>> suggestions for the syntax.
>
> The only way for the C++ programmer to route values into functions is
> to pass them individually. Some languages support unpacking primitive
> tuples as arguments (and C++ only requires adding a wrapper function),
> but in your example the programmer would still need to name the items
> individually.
>
> However, programmer notation has no bearing on object code generation.
> If your hardware has some distinct addresses for multiple return
> values, which need to be coded in a subsequent CALL instruction, then
> your code generator will need to detect the way data is being routed
> given intermediate-level program representation.
It doesn't have such addresses. The above code fragment (in Mill
assembler) totals two call operations on one instruction (the Mill is a
wide-issue machine in which an instruction can contain more than one
operation, and yes, the operations can be calls). The actual asm code
for the above is:
calln(f, 2), call0(g, b1, b0);
where comma separates ops and semicolon separates instructions.
>
>>> with each element of the tuple being able to be mapped to your return
>>> values? For a compiler targeting your architecture, is there anything
>>> that prevents the optimizer from decomposing the std::tuple into
>>> multiple, in-hardware return values?
>> Not that I know of, unless the function is bound at link time and not
>> visible to the optimizer. In that case the distinction between
>> returning a tuple-type object and returning multiple values becomes
>> ambiguous. This problem is present whenever the optimizer is proposed
>> to finesse imputed types that don't actually exist in the type
>> system. I'm hoping to actually extend the type system for function
>> types to include genuine multi-result types. We expect to add
>> whatever extension we come up with to clang and gcc; this is not an
>> academic exercise.
>
> The first task in a compiler port is to design an ABI, so I suggest
> you specify aggregate return values to go into multiple registers. Is
> there a reason this wouldn't work as the general case?
Yes, there are reasons. To begin with, there are no registers.
> (And is there any other possible programmer intent in returning an
> aggregate type?)
How about assigning to a variable of the aggregate type? Or passing to a
function that expects the aggregate type? Or to printf, for a comical case.
--
---
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/.
--------------070709010408030009060802
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 6/9/2014 10:20 PM, David Krauss
wrote:<br>
</div>
<blockquote
cite="mid:3462B425-139B-44FB-8F6D-838BFC11D6C0@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On 2014–06–10, at 12:51 PM, Ivan Godard <<a
moz-do-not-send="true" href="mailto:ivan@MillComputing.com">ivan@MillComputing.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">Consider a function F with two scalar
results, and a function G accepting two arguments of the
scalar type, where the intent is that the results of F will be
the arguments of G - in the opposite order. I was hoping for
something like:<br>
G([lab:f()] lab$1, lab$0)<br>
rather than the armwaving required to use tuples (note that I
am very much not proposing that syntax; my purpose here is to
gather suggestions for the syntax.<br>
</blockquote>
<div><br>
</div>
<div>The only way for the C++ programmer to route values into
functions is to pass them individually. Some languages support
unpacking primitive tuples as arguments (and C++ only requires
adding a wrapper function), but in your example the programmer
would still need to name the items individually.</div>
<div><br>
</div>
<div>However, programmer notation has no bearing on object code
generation. If your hardware has some distinct addresses for
multiple return values, which need to be coded in a subsequent
CALL instruction, then your code generator will need to detect
the way data is being routed given intermediate-level program
representation.</div>
</div>
</blockquote>
It doesn't have such addresses. The above code fragment (in Mill
assembler) totals two call operations on one instruction (the Mill
is a wide-issue machine in which an instruction can contain more
than one operation, and yes, the operations can be calls). The
actual asm code for the above is:<br>
<tt>c</tt><tt>alln(f, 2)</tt><tt>, call0(g, b1, b0);</tt><br>
where comma separates ops and semicolon separates instructions.<br>
<blockquote
cite="mid:3462B425-139B-44FB-8F6D-838BFC11D6C0@gmail.com"
type="cite">
<div>
<div><br>
</div>
<blockquote type="cite">
<blockquote type="cite">with each element of the tuple being
able to be mapped to your return<br>
values? For a compiler targeting your architecture, is
there anything<br>
that prevents the optimizer from decomposing the std::tuple
into<br>
multiple, in-hardware return values?<br>
</blockquote>
Not that I know of, unless the function is bound at link time
and not visible to the optimizer. In that case the distinction
between returning a tuple-type object and returning multiple
values becomes ambiguous. This problem is present whenever the
optimizer is proposed to finesse imputed types that don't
actually exist in the type system. I'm hoping to actually
extend the type system for function types to include genuine
multi-result types. We expect to add whatever extension we
come up with to clang and gcc; this is not an academic
exercise.<br>
</blockquote>
<div><br>
</div>
<div>The first task in a compiler port is to design an ABI, so I
suggest you specify aggregate return values to go into
multiple registers. Is there a reason this wouldn't work as
the general case?</div>
</div>
</blockquote>
Yes, there are reasons. To begin with, there are no registers.
<blockquote
cite="mid:3462B425-139B-44FB-8F6D-838BFC11D6C0@gmail.com"
type="cite">
<div>
<div> (And is there any other possible programmer intent in
returning an aggregate type?)</div>
</div>
</blockquote>
How about assigning to a variable of the aggregate type? Or passing
to a function that expects the aggregate type? Or to printf, for a
comical case.<br>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------070709010408030009060802--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 10 Jun 2014 14:38:02 +0800
Raw View
--Apple-Mail=_ACA12CE7-895B-4AF2-AF0E-4CABBCC61661
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-06-10, at 1:56 PM, Ivan Godard <ivan@MillComputing.com> wrote:
> The Mill is a new architecture. The return operation (also a hardware pri=
mitive) unwinds what the hardware call operation does.The Mill has no gener=
al registers, and values are SSA.
The point is that existing architectures support multiple returns, both thr=
ough returned aggregates and inlined calls.
> And it is up to the hardware designer to decide how close the hardware pr=
imitive should map to the language primitive.
Language primitives don't map directly to hardware primitives. These days, =
you really need to design hardware for an abstraction for which code genera=
tion is practical. You will need to support generic static compilation for =
the likes of C, and generic JIT for the likes of JavaScript. Anything else =
isn't really general-purpose, unless GPGPU is also "general-purpose."
> We are in the process of porting our toolchain to LLVM, and have found th=
at the IR makes some really egregious assumptions about the character of th=
e eventual target. For example, it assumes that pointers are integers.
According to http://llvm.org/docs/LangRef.html#pointer-type , each type has=
a corresponding pointer type as in C, but also there are multiple address =
spaces. The requirement that casts to integer type work may be a consequenc=
e of C support, or relying on a toolchain designed for C, but that's not LL=
VM's fault. In theory you should be able to do without (not support) such c=
asts, but why? Any bit-pattern can be an unsigned int.
As a semester project (back about 10 years ago), I targeted LLVM to a machi=
ne I designed with separate address and data registers (or something like t=
hat) and discovered that the generic compiler components were less amenable=
to things that are less like x86. Indeed, it's not perfect, but it's a lot=
better than nothing. I kludged my architecture and made it work; in real l=
ife there would have been a migration path back to where I'd intended to be=
..
Consider what happened to IA-64. For a long time it was thought capable of =
a little more, if the compiler were just better. Ultimately it turned out t=
o be merely on par, but at tremendous implementation cost.
>> Data-types are also merely human constructs that help organize programs.=
Even if you invent another formalism that avoids calling the return values=
a tuple, it will still be equally valid to treat them as such, because the=
difference is only in notation.
>>=20
> Are you sure of that? Consider a function returning a value of type T, an=
d a function returning a single-component tuple whose component is of type =
T. Is there truly no T for which the behavior of the two is different? I ha=
d thought there was.
I don't follow. I'm talking about computer science tuples, not std::tuple. =
If you invent a parallel system, it will still only parallel what we alread=
y have.
>> As for whether you might want a new mechanism, as opposed to more sugary=
tuples, are you prepared to sacrifice support or performance for programs =
that use tuples (or other aggregates) for this purpose?
>>=20
> The intent is that the extensions (this case, and others in process, whic=
h I may bring here) are proprietary, although if clang/gcc accepts them as =
contributions then they will be available to others. As for sacrificing per=
formance, we are considering alternatives precisely because the tuple appro=
ach so badly blows out the hardware performance.
Why? Do you need lifetime analysis to follow values through tuple packing/u=
npacking?
> Consider a function with two int results, and an expression that wants th=
e sum of them. On a Mill, using assembly language, that is two hardware ope=
rations - a call and an add. I have tried the corresponding tuple code in v=
arious compilation systems and targets available to me, and have been unabl=
e to get below 12 operations and some were over fifty. Your mileage may var=
y; if you have a platform that gets it to two then please post the source c=
ode used in the test, the target machine, and the compiler version and sett=
ings.
ICC reduces my test to nothing. It tracked the values through the pack and =
unpack, and added them as constants.
http://goo.gl/TZEABO
Perhaps this test is too simplistic, but where do you need the complexity t=
o be added?
> As might be expected for a hardware company, our forums are mostly popula=
ted by those interested in architecture rather than languages. Hence I have=
come here.
Specific examples of code that should be fast are more-or-less on topic her=
e. But, given the complexity of a competitive optimizer, you're going to ne=
ed to seriously leverage LLVM and/or GCC. Their development mailing lists s=
hould also be invaluable. You should be able to fix the bugs without resort=
ing to language extensions, at least as far as function inlining and LTO ca=
n reach.
--=20
---=20
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 e=
mail 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-proposa=
ls/.
--Apple-Mail=_ACA12CE7-895B-4AF2-AF0E-4CABBCC61661
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06–10, at 1:56 PM, Ivan Godard <<a href=3D"mailto:ivan@MillC=
omputing.com">ivan@MillComputing.com</a>> wrote:</div><br class=3D"Apple=
-interchange-newline"><blockquote type=3D"cite">
=20
<meta content=3D"text/html; charset=3DISO-8859-1" http-equiv=3D"Content=
-Type">
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><div class=3D"moz-cite-prefix">=
The Mill is a new architecture. The return operation (also a
hardware primitive) unwinds what the hardware call operation
does.The Mill has no general registers, and values are SSA.</div></div>=
</blockquote><div><br></div><div>The point is that existing architectures s=
upport multiple returns, both through returned aggregates and inlined calls=
..</div><br><blockquote type=3D"cite"><div bgcolor=3D"#FFFFFF" text=3D"#0000=
00">
And it is up to the hardware designer to decide how close the
hardware primitive should map to the language primitive. </div></blockq=
uote><div><br></div><div>Language primitives don’t map directly to ha=
rdware primitives. These days, you really need to design hardware for an ab=
straction for which code generation is practical. You will need to support =
generic static compilation for the likes of C, and generic JIT for the like=
s of JavaScript. Anything else isn’t really general-purpose, unless G=
PGPU is also “general-purpose.”</div><div><br></div><blockquote=
type=3D"cite"><div bgcolor=3D"#FFFFFF" text=3D"#000000">We are in the proc=
ess of
porting our toolchain to LLVM, and have found that the IR makes some
really egregious assumptions about the character of the eventual
target. For example, it assumes that pointers are integers.<br></div></=
blockquote><div><br></div><div>According to <a href=3D"http://llvm.org=
/docs/LangRef.html#pointer-type">http://llvm.org/docs/LangRef.html#pointer-=
type</a> , each type has a corresponding pointer type as in C, but also the=
re are multiple address spaces. The requirement that casts to integer type =
work may be a consequence of C support, or relying on a toolchain designed =
for C, but that’s not LLVM’s fault. In theory you should be abl=
e to do without (not support) such casts, but why? Any bit-pattern can be a=
n unsigned int.</div><div><br></div><div>As a semester project (back about =
10 years ago), I targeted LLVM to a machine I designed with separate addres=
s and data registers (or something like that) and discovered that the gener=
ic compiler components were less amenable to things that are less like x86.=
Indeed, it’s not perfect, but it’s a lot better than nothing. =
I kludged my architecture and made it work; in real life there would have b=
een a migration path back to where I’d intended to be.</div><div><br>=
</div><div>Consider what happened to IA-64. For a long time it was thought =
capable of a little more, if the compiler were just better. Ultimately it t=
urned out to be merely on par, but at tremendous implementation cost.</div>=
<br><blockquote type=3D"cite"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
<blockquote cite=3D"mid:1FE9C0E0-B191-4706-8EA3-054722B506B1@gmail.com"=
type=3D"cite"><div><div>Data-types are also merely human constructs that h=
elp
organize programs. Even if you invent another formalism that
avoids calling the return values a tuple, it will still be
equally valid to treat them as such, because the difference is
only in notation.</div>
<br>
</div>
</blockquote>
Are you sure of that? Consider a function returning a value of type
T, and a function returning a single-component tuple whose component
is of type T. Is there truly no T for which the behavior of the two
is different? I had thought there was.<br></div></blockquote><div><br><=
/div><div>I don’t follow. I’m talking about computer science tu=
ples, not <font face=3D"Courier">std::tuple</font>. If you invent a paralle=
l system, it will still only parallel what we already have.</div><br><block=
quote type=3D"cite"><div bgcolor=3D"#FFFFFF" text=3D"#000000"><blockquote c=
ite=3D"mid:1FE9C0E0-B191-4706-8EA3-054722B506B1@gmail.com" type=3D"cite"><d=
iv><div>As for whether you might want a new mechanism, as opposed
to more sugary tuples, are you prepared to sacrifice support
or performance for programs that use tuples (or other
aggregates) for this purpose?</div>
<br>
</div>
</blockquote>
The intent is that the extensions (this case, and others in process,
which I may bring here) are proprietary, although if clang/gcc
accepts them as contributions then they will be available to others.
As for sacrificing performance, we are considering alternatives
precisely because the tuple approach so badly blows out the hardware
performance.<br></div></blockquote><div><br></div><div>Why? Do you need=
lifetime analysis to follow values through tuple packing/unpacking?</div><=
br><blockquote type=3D"cite"><div bgcolor=3D"#FFFFFF" text=3D"#000000">Cons=
ider a function with two int results, and an expression that
wants the sum of them. On a Mill, using assembly language, that is
two hardware operations - a call and an add. I have tried the
corresponding tuple code in various compilation systems and targets
available to me, and have been unable to get below 12 operations and
some were over fifty. Your mileage may vary; if you have a platform
that gets it to two then please post the source code used in the
test, the target machine, and the compiler version and settings.<br></d=
iv></blockquote><div><br></div><div>ICC reduces my test to nothing. It trac=
ked the values through the pack and unpack, and added them as constants.</d=
iv><div><br></div><a href=3D"http://goo.gl/TZEABO">http://goo.gl/TZEABO</a>=
</div><div><br></div><div>Perhaps this test is too simplistic, but where do=
you need the complexity to be added?</div><div><br><blockquote type=3D"cit=
e"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
As might be expected for a hardware company, our forums are mostly
populated by those interested in architecture rather than languages.
Hence I have come here.<br></div></blockquote><div><br></div><div>Speci=
fic examples of code that should be fast are more-or-less on topic here. Bu=
t, given the complexity of a competitive optimizer, you’re going to n=
eed to seriously leverage LLVM and/or GCC. Their development mailing lists =
should also be invaluable. You should be able to fix the bugs without resor=
ting to language extensions, at least as far as function inlining and LTO c=
an reach.</div><div><br></div></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--Apple-Mail=_ACA12CE7-895B-4AF2-AF0E-4CABBCC61661--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 10 Jun 2014 14:48:58 +0800
Raw View
On 2014-06-10, at 2:12 PM, Ivan Godard <ivan@MillComputing.com> wrote:
>=20
> On 6/9/2014 10:20 PM, David Krauss wrote:
>> The first task in a compiler port is to design an ABI, so I suggest you =
specify aggregate return values to go into multiple registers. Is there a r=
eason this wouldn't work as the general case?
> Yes, there are reasons. To begin with, there are no registers.
I mean, is there a reason to treat multiple returns separately from aggrega=
te returns.
Of course there are hardware registers, regardless of what the ISA codes.
>> (And is there any other possible programmer intent in returning an aggre=
gate type?)
> How about assigning to a variable of the aggregate type? Or passing to a =
function that expects the aggregate type? Or to printf, for a comical case.
I don't see how any of these are a problem. If you're crossing a linkage bo=
undary where code on either side doesn't know the optimal format for the ot=
her side, then the data needs to be "serialized" in a standard way. Otherwi=
se, you really need lifetime analysis and inlining to eliminate the pack/un=
pack operation. Not a super tall order, but perhaps a serious chink in the =
armor.
You will need to model the "belt" as registers to get anywhere. But this is=
all below the conceptual level of C++, which really only specifies that va=
lues get from point A to point B, and that things whose addresses are taken=
must reside definitively at a particular address.
--=20
---=20
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 e=
mail 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-proposa=
ls/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 10 Jun 2014 08:54:17 +0200
Raw View
Em seg 09 jun 2014, =E0s 22:56:29, Ivan Godard escreveu:
> Consider a function with two int results, and an expression that wants=20
> the sum of them. On a Mill, using assembly language, that is two=20
> hardware operations - a call and an add. I have tried the corresponding=
=20
> tuple code in various compilation systems and targets available to me,=20
> and have been unable to get below 12 operations and some were over=20
> fifty. Your mileage may vary; if you have a platform that gets it to two=
=20
> then please post the source code used in the test, the target machine,=20
> and the compiler version and settings.
On the x86-64 and IA-64 Linux ABIs, the return of an aggregate of 2 integra=
ls=20
should be done entirely on registers. So code like this:
struct C { long i, j; }
C f();=20
long g()
{=20
auto v =3D f();=20
return v.i + v.j;
}
Does expand to a call instruction and an add (plus any frame marker overhea=
d).
I don't know why the above doesn't work for std::tuple -- it must be violat=
ing=20
one of the ABI for return in registers, but I haven't verified which one. I=
n=20
any case, that's a subject to be discussed in the ABI forums, not in the C+=
+=20
standard group.=20
The fact is that C++ does allow multiple values to be returned, even if the=
=20
syntax is clumsy. Your architecture does not need an extension. We all just=
=20
need an unclumsy solution, for all architectures.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=20
---=20
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 e=
mail 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-proposa=
ls/.
.
Author: Ivan Godard <ivan@MillComputing.com>
Date: Tue, 10 Jun 2014 00:06:03 -0700
Raw View
This is a multi-part message in MIME format.
--------------090509070502040802090700
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Dear me! I seem to have pushed a few buttons. Unintentionally I assure you.
On 6/9/2014 10:35 PM, David Krauss wrote:
>
> On 2014--06--10, at 11:18 AM, Patrick Michael Niedzielski
> <patrickniedzielski@gmail.com <mailto:patrickniedzielski@gmail.com>>
> wrote:
>
>> Why was this "homework assignment" comment was necessary? Be civil.
>
> Homework is the only justification for ignoring a widely implemented
> solution for the sake of implementing something new.
>
Not ignored, but not satisfied with either.
> There's no shame in doing homework, but insisting on inventing
> something for novelty's sake is Wrong. What we have here is a man in
> search of a solution in search of a problem. He doesn't know what his
> extension is yet, he just knows he wants some kind of an extension.
> C++ handles multiple returns essentially the same as any other
> language, but it's a "kludge" because it's not bespoke.
>
I find it to be kludgy (IMHO) because it breaks the natural flow of
expressions, and I deem expression languages to be the superior approach
to imperatives. Granted YMMV, and I show my Algol68 and Mary heritage.
However, other languages have a much less lumpy exterior when faced with
this problem: multiple returns express naturally in pure dataflow
languages, and even Ada does a better job using OUT parameters.
> Presupposition that new solutions are needed is not the way an
> engineer should think. Prototypes are built using the parts on hand,
> and no evidence has so far been presented that the parts do not fit.
Are you really advocating that, so long as you can squint and make a
problem look kinda like a nail, there's no merit in considering what
else than hammers might be usable?
> If we need more detail about multiple returns, it should be described
> within the immediate request and not left in the middle of an
> hours-long video series.
>
My apologies; I had assumed that all readers of this board would
understand what a "function returning multiple results" meant. Actually,
I'm not sure I could explain it better.
>> The past few emails you've sent in this thread have not come off as
>> civil.
>
> The first post immediately raised red flags. The assertion that a new
> CPU architecture is completely different from everything else is
> immediately suspicious, because after 60+ years of experimentation
> there are few completely novel ideas.
Quite true. Nearly all the CPU advances in the last 30 years have been
in the fab; a Haswell would look very familiar to the designer of the
360/91, or even the STRETCH. Unfortunately, Moore's law is no longer
with us. The last major architectural advance was the introduction of
caches.
And that's why we felt that there was a market for a new architecture.
It couldn't be the incremental evolutionary improvement that produced
what we use today; to break a startup into the market requires something
that is *very* different. We put in a decade doing that, and you are
welcome to visit our site to see how it works to the extent that you are
able to; our published material is intended primarily for architects and
hardware designers.
> To communicate architectural details to a literate audience, it is
> expedient to reference literature.
For academics, I suppose. We have found that to describe dynamic
processes (and the guts of a CPU is nothing but dynamic) it really helps
to have pictures, and especially animated pictures. As the purpose of
our published material is to explain the machine to those who could
implement it, we don't really care if they qualify as "literate".
> Following the YouTube link and checking the website via archive.org
> <http://archive.org> reinforces my impression that the materials, by
> intention or not, are geared to an illiterate audience of potential
> investors. This rubs me the wrong way.
>
You leapt to conclusions. No "investor" without a background in CPU
architecture would understand it.
> Anyone with the experience to do what Ivan says he did, knows that
> multiple returns are commonplace in handwritten assembler for any
> conventional register-based architecture.
Yes; there's no problem in asm. I came here hoping for C++ help.
> (Even more common for stack machines.) So the assertion that they're
> unsupported is just disingenuous. Even variable length returns are
> easily done with a call stack, and there is precedent for putting the
> stack in rename registers. This has nothing to do with C++, by the way.
>
>> <https://www.youtube.com/watch?v=QGw-cy0ylCc>
>
> "DSP code, all those loops are software pipelined, and software
> pipelines have unbounded ILP."
>
> Even DSP filters often have dependencies over loop iterations.
>
While part of what we do for pipes is covered in other talks (see
http://millcomputing.com/docd/metadata), our upcoming talk (early July
at FaceBook) will go into it in greater detail, and in particular how
the hardware deals with loop-carried data, including reductions.
> "Rather few general-purpose loops can be software pipelined. They
> contain really nasty things like function calls, that are full of
> control."
>
> No, they cannot be pipelined because of Amdahl's law: you can only go
> so far before hitting a dependent computation.
>
Well, I suppose that is a good argument for leaving things as they are.
> "Any of you who do do chip design know I'm lying through my teeth"
>
> Well, I have done a smidgen of physical circuit design, and I'd like
> to see what magic network wiring can be a game-changer.
>
None of our advantages are at the circuit or fab level; we use
bog-standard cell libraries.
> ---
>
> I'll stop now and get back to work, but civility is not the best thing
> when it comes to scammers.
You might try it :-)
> Big dreams are well and good, but asking money for research that
> requires no materials, misrepresenting the degree of originality, is
> unjustified.
I'm not sure where you got the idea that we are asking for money. There
is no such request on our site, and we are not seeking grants of any
kind. We do now have investors, who have sought us out, but for the
first decade of our work we were entirely a self-funded bootstrap
organization. I have been full time on the Mill from the beginning, and
this year is the first time that I have had a paycheck. Frankly, being
called a scammer I find rather objectionable; that such behavior is
permitted here speaks poorly for this board. My complements to Patrick
Niedzielski; thank you for speaking for civility.
> Claiming that additional language support is needed when its not,
That is not my claim: I stated that I found the conventional
alternatives somewhat unsatisfactory (and gave reasons) and ask for help
and advice in search for alternatives that could be used as extensions.
There may not be alternatives; if I were sure then I would not have
needed to bother this board. To respond that the search is wrongheaded
and due to base motives will certainly serve to keep disruptive
outsiders away from the pure and righteous.
Perhaps that is the intent, but it's not the way we run our railroad in
the Mill project..
> and such requirement of extensions being a historical reason for
> /failure/ of projects just like this, is disingenuous. There's no
> problem with Ivan pursuing personal projects, but the connections
> drawn in messages here between C++ notation and machine code suggest a
> lack of the familiarity with modern compilers that is essential to ISA
> design. Acting like a seasoned pro with a comp-arch business plan, but
> without familiarity with the software development stack, is fraud.
>
Yeah. This is pointless, so I'll withdraw. If any lurkers would like to
continue this off the board you can reach me at ivan@millcomputing .com,
or post comments at http://millcomputing/forums.
> TL;DR: If he wants to succeed, he will avoid language extensions and
> use pure LLVM IR as source. If the project is for real, it can take my
> flak. If it's not, I'm doing skeptics a valuable service with public
> criticism.
>
And we thank you for your public-spirited gesture.
Ivan
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/4g3NYpKwQX0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org
> <mailto:std-proposals+unsubscribe@isocpp.org>.
> To post to this group, send email to std-proposals@isocpp.org
> <mailto:std-proposals@isocpp.org>.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--
---
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/.
--------------090509070502040802090700
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Dear me! I seem to have pushed a few buttons. Unintentionally I
assure you.<br>
<br>
<div class="moz-cite-prefix">On 6/9/2014 10:35 PM, David Krauss
wrote:<br>
</div>
<blockquote
cite="mid:21133552-0B6F-4307-8229-4B61CEC5365E@gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<br>
<div>
<div>On 2014–06–10, at 11:18 AM, Patrick Michael Niedzielski
<<a moz-do-not-send="true"
href="mailto:patrickniedzielski@gmail.com">patrickniedzielski@gmail.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">Why was this "homework assignment"
comment was necessary? Be civil.<br>
</blockquote>
<div><br>
</div>
<div>Homework is the only justification for ignoring a widely
implemented solution for the sake of implementing something
new.</div>
<div><br>
</div>
</div>
</blockquote>
Not ignored, but not satisfied with either. <br>
<blockquote
cite="mid:21133552-0B6F-4307-8229-4B61CEC5365E@gmail.com"
type="cite">
<div>
<div>There’s no shame in doing homework, but insisting on
inventing something for novelty’s sake is Wrong. What we have
here is a man in search of a solution in search of a problem.
He doesn’t know what his extension is yet, he just knows he
wants some kind of an extension. C++ handles multiple returns
essentially the same as any other language, but it’s a
“kludge” because it’s not bespoke.</div>
<div><br>
</div>
</div>
</blockquote>
I find it to be kludgy (IMHO) because it breaks the natural flow of
expressions, and I deem expression languages to be the superior
approach to imperatives. Granted YMMV, and I show my Algol68 and
Mary heritage. However, other languages have a much less lumpy
exterior when faced with this problem: multiple returns express
naturally in pure dataflow languages, and even Ada does a better job
using OUT parameters.<br>
<blockquote
cite="mid:21133552-0B6F-4307-8229-4B61CEC5365E@gmail.com"
type="cite">
<div>
<div>Presupposition that new solutions are needed is not the way
an engineer should think. Prototypes are built using the parts
on hand, and no evidence has so far been presented that the
parts do not fit.</div>
</div>
</blockquote>
Are you really advocating that, so long as you can squint and make a
problem look kinda like a nail, there's no merit in considering what
else than hammers might be usable?<br>
<blockquote
cite="mid:21133552-0B6F-4307-8229-4B61CEC5365E@gmail.com"
type="cite">
<div>
<div> If we need more detail about multiple returns, it should
be described within the immediate request and not left in the
middle of an hours-long video series.</div>
<br>
</div>
</blockquote>
My apologies; I had assumed that all readers of this board would
understand what a "function returning multiple results" meant.
Actually, I'm not sure I could explain it better.<br>
<blockquote
cite="mid:21133552-0B6F-4307-8229-4B61CEC5365E@gmail.com"
type="cite">
<div>
<blockquote type="cite">The past few emails you've sent in this
thread have not come off as<br>
civil.<br>
</blockquote>
<div><br>
</div>
<div>The first post immediately raised red flags. The assertion
that a new CPU architecture is completely different from
everything else is immediately suspicious, because after 60+
years of experimentation there are few completely novel ideas.
</div>
</div>
</blockquote>
Quite true. Nearly all the CPU advances in the last 30 years have
been in the fab; a Haswell would look very familiar to the designer
of the 360/91, or even the STRETCH. Unfortunately, Moore's law is no
longer with us. The last major architectural advance was the
introduction of caches. <br>
<br>
And that's why we felt that there was a market for a new
architecture. It couldn't be the incremental evolutionary
improvement that produced what we use today; to break a startup into
the market requires something that is *very* different. We put in a
decade doing that, and you are welcome to visit our site to see how
it works to the extent that you are able to; our published material
is intended primarily for architects and hardware designers.<br>
<blockquote
cite="mid:21133552-0B6F-4307-8229-4B61CEC5365E@gmail.com"
type="cite">
<div>
<div>To communicate architectural details to a literate
audience, it is expedient to reference literature. </div>
</div>
</blockquote>
For academics, I suppose. We have found that to describe dynamic
processes (and the guts of a CPU is nothing but dynamic) it really
helps to have pictures, and especially animated pictures. As the
purpose of our published material is to explain the machine to those
who could implement it, we don't really care if they qualify as
"literate".<br>
<blockquote
cite="mid:21133552-0B6F-4307-8229-4B61CEC5365E@gmail.com"
type="cite">
<div>
<div>Following the YouTube link and checking the website via <a
moz-do-not-send="true" href="http://archive.org">archive.org</a>
reinforces my impression that the materials, by intention or
not, are geared to an illiterate audience of potential
investors. This rubs me the wrong way.</div>
<div><br>
</div>
</div>
</blockquote>
You leapt to conclusions. No "investor" without a background in CPU
architecture would understand it. <br>
<blockquote
cite="mid:21133552-0B6F-4307-8229-4B61CEC5365E@gmail.com"
type="cite">
<div>
<div>Anyone with the experience to do what Ivan says he did,
knows that multiple returns are commonplace in handwritten
assembler for any conventional register-based architecture. </div>
</div>
</blockquote>
Yes; there's no problem in asm. I came here hoping for C++ help.<br>
<blockquote
cite="mid:21133552-0B6F-4307-8229-4B61CEC5365E@gmail.com"
type="cite">
<div>
<div>(Even more common for stack machines.) So the assertion
that they’re unsupported is just disingenuous. Even variable
length returns are easily done with a call stack, and there is
precedent for putting the stack in rename registers. This has
nothing to do with C++, by the way.</div>
<div><br>
</div>
<div>
<blockquote type="cite"><<a moz-do-not-send="true"
href="https://www.youtube.com/watch?v=QGw-cy0ylCc">https://www.youtube.com/watch?v=QGw-cy0ylCc</a>><br>
</blockquote>
</div>
<div><br>
</div>
<div>“DSP code, all those loops are software pipelined, and
software pipelines have unbounded ILP.”</div>
<div><br>
</div>
<div>Even DSP filters often have dependencies over loop
iterations.</div>
<div><br>
</div>
</div>
</blockquote>
While part of what we do for pipes is covered in other talks (see
<a class="moz-txt-link-freetext" href="http://millcomputing.com/docd/metadata">http://millcomputing.com/docd/metadata</a>), our upcoming talk (early
July at FaceBook) will go into it in greater detail, and in
particular how the hardware deals with loop-carried data, including
reductions.<br>
<blockquote
cite="mid:21133552-0B6F-4307-8229-4B61CEC5365E@gmail.com"
type="cite">
<div>
<div>“Rather few general-purpose loops can be software
pipelined. They contain really nasty things like function
calls, that are full of control."</div>
<div><br>
</div>
No, they cannot be pipelined because of Amdahl’s law: you can
only go so far before hitting a dependent computation.</div>
<div><br>
</div>
</blockquote>
Well, I suppose that is a good argument for leaving things as they
are.<br>
<blockquote
cite="mid:21133552-0B6F-4307-8229-4B61CEC5365E@gmail.com"
type="cite">
<div>“Any of you who do do chip design know I’m lying through my
teeth”</div>
<div><br>
</div>
<div>Well, I have done a smidgen of physical circuit design, and
I’d like to see what magic network wiring can be a game-changer.</div>
<div><br>
</div>
</blockquote>
None of our advantages are at the circuit or fab level; we use
bog-standard cell libraries.<br>
<blockquote
cite="mid:21133552-0B6F-4307-8229-4B61CEC5365E@gmail.com"
type="cite">
<div>—</div>
<div><br>
</div>
<div>I’ll stop now and get back to work, but civility is not the
best thing when it comes to scammers. </div>
</blockquote>
You might try it :-)<br>
<blockquote
cite="mid:21133552-0B6F-4307-8229-4B61CEC5365E@gmail.com"
type="cite">
<div>Big dreams are well and good, but asking money for research
that requires no materials, misrepresenting the degree of
originality, is unjustified. </div>
</blockquote>
I'm not sure where you got the idea that we are asking for money.
There is no such request on our site, and we are not seeking grants
of any kind. We do now have investors, who have sought us out, but
for the first decade of our work we were entirely a self-funded
bootstrap organization. I have been full time on the Mill from the
beginning, and this year is the first time that I have had a
paycheck. Frankly, being called a scammer I find rather
objectionable; that such behavior is permitted here speaks poorly
for this board. My complements to Patrick Niedzielski; thank you for
speaking for civility.<br>
<br>
<blockquote
cite="mid:21133552-0B6F-4307-8229-4B61CEC5365E@gmail.com"
type="cite">
<div>Claiming that additional language support is needed when its
not,</div>
</blockquote>
That is not my claim: I stated that I found the conventional
alternatives somewhat unsatisfactory (and gave reasons) and ask for
help and advice in search for alternatives that could be used as
extensions. There may not be alternatives; if I were sure then I
would not have needed to bother this board. To respond that the
search is wrongheaded and due to base motives will certainly serve
to keep disruptive outsiders away from the pure and righteous.<br>
<br>
Perhaps that is the intent, but it's not the way we run our railroad
in the Mill project..<br>
<blockquote
cite="mid:21133552-0B6F-4307-8229-4B61CEC5365E@gmail.com"
type="cite">
<div> and such requirement of extensions being a historical reason
for <i>failure</i> of projects just like this, is disingenuous.
There’s no problem with Ivan pursuing personal projects, but the
connections drawn in messages here between C++ notation and
machine code suggest a lack of the familiarity with modern
compilers that is essential to ISA design. Acting like a
seasoned pro with a comp-arch business plan, but without
familiarity with the software development stack, is fraud.</div>
<div><br>
</div>
</blockquote>
Yeah. This is pointless, so I'll withdraw. If any lurkers would like
to continue this off the board you can reach me at
ivan@millcomputing .com, or post comments at
<a class="moz-txt-link-freetext" href="http://millcomputing/forums">http://millcomputing/forums</a>.<br>
<blockquote
cite="mid:21133552-0B6F-4307-8229-4B61CEC5365E@gmail.com"
type="cite">
<div>TL;DR: If he wants to succeed, he will avoid language
extensions and use pure LLVM IR as source. If the project is for
real, it can take my flak. If it’s not, I’m doing skeptics a
valuable service with public criticism.</div>
<div><br>
</div>
</blockquote>
And we thank you for your public-spirited gesture.<br>
<br>
Ivan<br>
<blockquote
cite="mid:21133552-0B6F-4307-8229-4B61CEC5365E@gmail.com"
type="cite">
-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in
the Google Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a moz-do-not-send="true"
href="https://groups.google.com/a/isocpp.org/d/topic/std-proposals/4g3NYpKwQX0/unsubscribe">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/4g3NYpKwQX0/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email
to <a moz-do-not-send="true"
href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a moz-do-not-send="true"
href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a moz-do-not-send="true"
href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--------------090509070502040802090700--
.
Author: Ivan Godard <ivan@MillComputing.com>
Date: Tue, 10 Jun 2014 01:13:10 -0700
Raw View
On 6/9/2014 11:54 PM, Thiago Macieira wrote:
> <snip>
> The fact is that C++ does allow multiple values to be returned, even
> if the syntax is clumsy. Your architecture does not need an extension.
> We all just need an unclumsy solution, for all architectures.
Agreed.
However, I have an architecture to support, and have neither time nor
money nor interest in improving C++ outside that context, except as a
side effect. We are a commercial company, not an academy or government
agency, and if we are going to pay engineers to work on compilers it has
to directly benefit our product. On the other hand, we all benefit from
the community and we want to support it to the extent we can, so if we
were to come up with an unclumsy solution then we would contribute it to
clang and gcc so others could have practical experience with it, and
eventually standardize it if deemed worthy.
I had hoped that others might already have found the present C++ clumsy
enough that they had already kicked ideas around but just hadn't had the
resources to put them in the compilers to try out. Then our compiler
work, on our nickel, with our platform underneath, would give the
language community a real opportunity for exploration and experience,
while getting better use out of our hardware.
Instead I learn that not only is the present mechanism not clumsy, it is
so perfect as to be above examination. So much for my fraudulent attempt
to scam C++.
Ivan
--
---
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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 10 Jun 2014 10:42:33 +0200
Raw View
Em ter 10 jun 2014, =E0s 01:13:10, Ivan Godard escreveu:
> I had hoped that others might already have found the present C++ clumsy
> enough that they had already kicked ideas around but just hadn't had the
> resources to put them in the compilers to try out. Then our compiler
> work, on our nickel, with our platform underneath, would give the
> language community a real opportunity for exploration and experience,
> while getting better use out of our hardware.
>=20
> Instead I learn that not only is the present mechanism not clumsy, it is
> so perfect as to be above examination. So much for my fraudulent attempt
> to scam C++.
Did you search the archives? DId you see the email that pointed out to the=
=20
paper on this exact subject?
From reading all the emails in this thread, it seems that you got off on th=
e=20
wrong foot by trying to make something that is special for your architectur=
e.=20
You can bet that we 99% of the people here couldn't care less about your=20
architecture. We're not stake holders in it -- and many of us, including me=
,=20
are actually stakeholders in competitors.
Instead, the discussion should have focused only and exclusively on multipl=
e=20
result. See also the threads "C++ named tuple", "Unpacking syntax for tuple=
s=20
using auto", and a few others.
So, no, the status is not that we think the current solution is perfect. Fa=
r=20
from it. There's a lot of room to improve and you can and should contribute=
to=20
it.
But your attitude isn't helping.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=20
---=20
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 e=
mail 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-proposa=
ls/.
.
Author: Ivan Godard <ivan@MillComputing.com>
Date: Tue, 10 Jun 2014 02:30:10 -0700
Raw View
On 6/10/2014 1:42 AM, Thiago Macieira wrote:
> Em ter 10 jun 2014, =E0s 01:13:10, Ivan Godard escreveu:
>> I had hoped that others might already have found the present C++ clumsy
>> enough that they had already kicked ideas around but just hadn't had the
>> resources to put them in the compilers to try out. Then our compiler
>> work, on our nickel, with our platform underneath, would give the
>> language community a real opportunity for exploration and experience,
>> while getting better use out of our hardware.
>>
>> Instead I learn that not only is the present mechanism not clumsy, it is
>> so perfect as to be above examination. So much for my fraudulent attempt
>> to scam C++.
> Did you search the archives?
No. I have no idea where the archives are. I did ask for pointers, if=20
you recall. I came here after finding nothing new to me in a Google of=20
"multi-result functions in C++", expecting that I might find better=20
search keys here, or other useful pointers.
> DId you see the email that pointed out to the
> paper on this exact subject?
No. Whose email was it? Can you repeat the pointer? Pretty much=20
everything I have seen in postings so far has appeared to be about the=20
tuple solution, but I don't need info about that.
> >From reading all the emails in this thread, it seems that you got off on=
the
> wrong foot by trying to make something that is special for your architect=
ure.
> You can bet that we 99% of the people here couldn't care less about your
> architecture. We're not stake holders in it -- and many of us, including =
me,
> are actually stakeholders in competitors.
Well, in all innocence I was trying to motivate why I showed up a=20
stranger on this board, admittedly unfamiliar with its denizens and=20
conventions. I thought providing the context was a courtesy, but it=20
appears to have been seen as an attack.
It had been my understanding that a common path for additions to the=20
standard was for an interested party with an idea would implement the=20
idea as an extension in one of the widely used compilers (or boost for=20
something that could be done as a library). After experience with the=20
implementation, the community would then reject the idea, accept it, or=20
improve it, and eventually someone (possibly not the original=20
implementer) would draft it up as a proposal with all the proper=20
phrasing, and eventually, if not rejected, the idea would be enshrined.
As we will be porting the compilers anyway, it seemed not much more work=20
to see what we could come up with and incorporate it; if the idea turned=20
out to be sound then all benefit, and if not then the experience with=20
implementation and use should soon reveal that. I even naively thought=20
that the community here would be happy that someone was willing to pay=20
for the work involved in such exploration.
> Instead, the discussion should have focused only and exclusively on multi=
ple
> result. See also the threads "C++ named tuple", "Unpacking syntax for tup=
les
> using auto", and a few others.
I shall, although the titles suggest more on tuples. Can you expand on=20
"a few others"?
> So, no, the status is not that we think the current solution is perfect. =
Far
> from it. There's a lot of room to improve and you can and should contribu=
te to
> it.
Begging your pardon, but why would I want to after such a welcome? At=20
least in the circles that I do contribute to, people sometimes tell me=20
my stuff won't work, and people sometimes tell me it could be done=20
better, and people sometimes tell me the goals and approach are=20
wrong-headed, and people sometimes tell me I'm a newbie and should be=20
quiet until I learn more, but they don't call me a fraud.
> But your attitude isn't helping.
>
Really?
--=20
---=20
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 e=
mail 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-proposa=
ls/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 10 Jun 2014 13:12:40 +0300
Raw View
On 10 June 2014 11:42, Thiago Macieira <thiago@macieira.org> wrote:
> Instead, the discussion should have focused only and exclusively on multiple
> result. See also the threads "C++ named tuple", "Unpacking syntax for tuples
> using auto", and a few others.
>
> So, no, the status is not that we think the current solution is perfect. Far
> from it. There's a lot of room to improve and you can and should contribute to
> it.
I have thought of figuring out a way to have multiple return values in
c++ a couple of
times. Every time, I have failed to find sufficient motivation for it.
I can return pairs,
tuples, custom structs, function-local structs (in c++14, with return
type deduction),
or use return-via argument (with either default-argument pointers that
users don't
need to provide, or with multiple overloads so that the don't-care-cases don't
bother either the caller or the callee), and the remaining cases where
I'd really
want multiple independent return values seem vanishingly rare.
The cases where I'd want to unpack into independent variables instead
of just using a
struct are even more vanishingly rare. Yeah, sure, python and lisp
give me nice tools for
such vanishingly rare cases, but I fail to convince even myself that
such a facility
is necessary, let alone convince anyone else. Solutions that muck with
declarator
syntax certainly don't seem worth the trouble.
Selling multiple return values as a new feature is going to be quite
hard, I expect.
The motivation seems weak, the use cases seem rare, and it has been discussed
quite many times with no new results coming out of those discussions.
--
---
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/.
.
Author: Ivan Godard <ivan@MillComputing.com>
Date: Tue, 10 Jun 2014 03:36:29 -0700
Raw View
On 6/10/2014 3:12 AM, Ville Voutilainen wrote:
> On 10 June 2014 11:42, Thiago Macieira <thiago@macieira.org> wrote:
>> Instead, the discussion should have focused only and exclusively on multiple
>> result. See also the threads "C++ named tuple", "Unpacking syntax for tuples
>> using auto", and a few others.
>>
>> So, no, the status is not that we think the current solution is perfect. Far
>> from it. There's a lot of room to improve and you can and should contribute to
>> it.
>
> I have thought of figuring out a way to have multiple return values in
> c++ a couple of
> times. Every time, I have failed to find sufficient motivation for it.
> I can return pairs,
> tuples, custom structs, function-local structs (in c++14, with return
> type deduction),
> or use return-via argument (with either default-argument pointers that
> users don't
> need to provide, or with multiple overloads so that the don't-care-cases don't
> bother either the caller or the callee), and the remaining cases where
> I'd really
> want multiple independent return values seem vanishingly rare.
>
> The cases where I'd want to unpack into independent variables instead
> of just using a
> struct are even more vanishingly rare. Yeah, sure, python and lisp
> give me nice tools for
> such vanishingly rare cases, but I fail to convince even myself that
> such a facility
> is necessary, let alone convince anyone else. Solutions that muck with
> declarator
> syntax certainly don't seem worth the trouble.
>
> Selling multiple return values as a new feature is going to be quite
> hard, I expect.
> The motivation seems weak, the use cases seem rare, and it has been discussed
> quite many times with no new results coming out of those discussions.
>
Users of languages with OUT and INOUT parameters seem to make quite
heavy use of them, which suggests that the (semantically equivalent)
multi-result functions should be equally common. Perhaps the infrequent
need that you report is due in part to the inconvenience of the
notation, so you never got into the habit of using value-result arguments?
Users of those languages also assert that it is much easier to prove
correctness, and in general to reason about programs, when using
value-result rather than when using pass-by-reference; this is
especially true when reasoning about concurrent behavior in
multithreaded applications. While it is true that a compiler can (often)
determine that a by-reference parameter is really an OUT parameter, it
is rather more difficult for a mere human to do so, and even compilers
have problems when the analysis scope is less than whole program
optimization.
--
---
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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 10 Jun 2014 13:47:37 +0300
Raw View
On 10 June 2014 13:36, Ivan Godard <ivan@millcomputing.com> wrote:
> Users of languages with OUT and INOUT parameters seem to make quite heavy
> use of them, which suggests that the (semantically equivalent) multi-result
> functions should be equally common. Perhaps the infrequent need that you
> report is due in part to the inconvenience of the notation, so you never got
> into the habit of using value-result arguments?
For all purposes I've ever needed them, I already have out parameters in C++,
and I have had zero problems with T&, I've never felt a need for an
'out T'. There
is hardly any inconvenience of notation, returning a struct is as convenient
as I need it to be. Tuples are less than convenient due to having to use
std::get<N>, which isn't very readable. Pairs are more convenient, although
..first and .second are not exactly meaning-conveying either.
> Users of those languages also assert that it is much easier to prove
> correctness, and in general to reason about programs, when using
> value-result rather than when using pass-by-reference; this is especially
> true when reasoning about concurrent behavior in multithreaded applications.
> While it is true that a compiler can (often) determine that a by-reference
> parameter is really an OUT parameter, it is rather more difficult for a mere
> human to do so, and even compilers have problems when the analysis scope is
> less than whole program optimization.
I should probably mention that if std::expected lands into C++,
there's yet fewer
cases where I'd ever resort to returning multiple values.
But by all means, if you want, write a proposal. I'm merely trying to
point out what
the likely counterarguments are going to be. And do keep in mind that those
counterarguments will likely be raised by EWG members who have a fair bit
of influence. The proposals for this facility have never succeeded
before, so having it succeed
now would, to me, logically, require better motivation/rationale than
earlier attempts
of it. Thus far I don't think I have seen any new arguments for the facility.
--
---
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/.
.
Author: Edward Catmur <ed@catmur.co.uk>
Date: Tue, 10 Jun 2014 04:07:46 -0700 (PDT)
Raw View
------=_Part_150_4656530.1402398466342
Content-Type: text/plain; charset=UTF-8
>
> Consider a function F with two scalar results, and a function G
> accepting two arguments of the scalar type, where the intent is that the
> results of F will be the arguments of G - in the opposite order. I was
> hoping for something like:
> G([lab:f()] lab$1, lab$0)
> rather than the armwaving required to use tuples (note that I am very
> much not proposing that syntax; my purpose here is to gather suggestions
> for the syntax.
>
Three ways to write that with current syntax:
void x() {
[](auto lab) { return g(std::get<1>(lab), std::get<0>(lab)); }(f());
}
void y() {
[](decltype(f()) lab=f()) { return g(std::get<1>(lab), std::get<0>(lab));
}();
}
void z() {
auto lab = f();
g(std::get<1>(lab), std::get<0>(lab));
}
Clang compiles all three identically (with f returning std::tuple<int,
double>):
pushq %rax
callq f()
movl %eax, %edi
popq %rax
jmp g(double, int) # TAILCALL
If clang can generate (to my eyes) optimal code on x86-64, an architecture
not specifically designed for multiple argument return, then it should be
able to do the same on your architecture, just as long as you get the ABI
right. There doesn't seem to be any justification for new syntax from the
point of view of performance.
I'm not saying the above syntax is perfect - it's clearly pretty clumsy -
but it's clearly expressive enough to communicate to both the reader and
the optimizer the intended behavior.
With Peter Sommerlad's apply[1] and a little helper function permute one
can write:
std::apply(g, permute<1, 0>(f()))
Again, clang produces identical code.
1. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3802.pdf
--
---
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_150_4656530.1402398466342
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Consider a fu=
nction F with two scalar results, and a function G=20
<br>accepting two arguments of the scalar type, where the intent is that th=
e=20
<br>results of F will be the arguments of G - in the opposite order. I was=
=20
<br>hoping for something like:
<br> &=
nbsp; G([lab:f()] lab$1, lab$0)
<br>rather than the armwaving required to use tuples (note that I am very=
=20
<br>much not proposing that syntax; my purpose here is to gather suggestion=
s=20
<br>for the syntax.
<br></blockquote><div><br></div><div>Three ways to write that with current =
syntax:</div><div><br></div><div><div class=3D"prettyprint" style=3D"border=
: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color: rg=
b(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">[](</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> lab</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> g</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">std</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">get</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
"><</span><span style=3D"color: #066;" class=3D"styled-by-prettify">1</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">>(</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">lab</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">),</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">get</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify"><</span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>lab</span><span style=3D"color: #660;" class=3D"styled-by-prettify">));</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">}(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">f</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">());</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> y</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">[](</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">decltype</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify">f</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">())</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> lab</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">())</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> g</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">get=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">>(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">lab</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">),</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">get</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify"><</span><span style=3D"color: #066;" class=3D"styled-by-prett=
ify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>=
(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">lab</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">));</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">}();</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> z</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> lab </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br> g</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
get</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</s=
pan><span style=3D"color: #066;" class=3D"styled-by-prettify">1</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">>(</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">lab</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">),</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">get</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify"><</span><span style=3D"color: #066;" class=3D"styled-by-pret=
tify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>=
;(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">lab</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">));</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></div><=
div><br></div></div><div>Clang compiles all three identically (with <font f=
ace=3D"courier new, monospace">f</font> returning <font face=3D"courier new=
, monospace">std::tuple<int, double></font>):</div><div><br></div><di=
v class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word=
-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> pushq </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">%</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">rax<br> callq f</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br> movl </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">%</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">eax</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">%</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">edi<br> popq <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">%</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">rax<br> jmp g</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">double</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> &n=
bsp;</span><span style=3D"color: #800;" class=3D"styled-by-prettify"># TAIL=
CALL</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span></div></code></div><div><br></div><div>If clang can generate (to my ey=
es) optimal code on x86-64, an architecture not specifically designed for m=
ultiple argument return, then it should be able to do the same on your arch=
itecture, just as long as you get the ABI right. There doesn't seem to be a=
ny justification for new syntax from the point of view of performance.</div=
><div><br></div><div>I'm not saying the above syntax is perfect - it's clea=
rly pretty clumsy - but it's clearly expressive enough to communicate to bo=
th the reader and the optimizer the intended behavior.</div><div><br></div>=
<div>With Peter Sommerlad's <font face=3D"courier new, monospace">apply</fo=
nt>[1] and a little helper function <font face=3D"courier new, monospace">p=
ermute</font> one can write:</div><div><br></div><div><div class=3D"prettyp=
rint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word;=
background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=
:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">apply</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">g</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> permute</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify"><</span><span style=3D"color: #066;" cla=
ss=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">f</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">()))</span></div></code>=
</div></div><div><br></div><div>Again, clang produces identical code.</div>=
<div><br></div><div>1. http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2013/n3802.pdf</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_150_4656530.1402398466342--
.
Author: Ivan Godard <ivan@MillComputing.com>
Date: Tue, 10 Jun 2014 04:23:37 -0700
Raw View
This is a multi-part message in MIME format.
--------------020100010009070906070102
Content-Type: text/plain; charset=UTF-8; format=flowed
On 6/10/2014 4:07 AM, Edward Catmur wrote:
>
> Consider a function F with two scalar results, and a function G
> accepting two arguments of the scalar type, where the intent is
> that the
> results of F will be the arguments of G - in the opposite order. I
> was
> hoping for something like:
> G([lab:f()] lab$1, lab$0)
> rather than the armwaving required to use tuples (note that I am very
> much not proposing that syntax; my purpose here is to gather
> suggestions
> for the syntax.
>
>
> Three ways to write that with current syntax:
>
> |
> voidx(){
> [](autolab){returng(std::get<1>(lab),std::get<0>(lab));}(f());
> }
> voidy(){
> [](decltype(f())lab=f()){returng(std::get<1>(lab),std::get<0>(lab));}();
> }
> voidz(){
> autolab =f();
> g(std::get<1>(lab),std::get<0>(lab));
> }
> |
>
> Clang compiles all three identically (with f returning std::tuple<int,
> double>):
>
> |
> pushq %rax
> callq f()
> movl %eax,%edi
> popq %rax
> jmp g(double,int)# TAILCALL
> |
>
>
<snip>
Thank you; this is much better than I had seen before. If the compiler
is as effective on other cases then it lays my concerns about
performance to rest.
--
---
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/.
--------------020100010009070906070102
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
<div class=3D"moz-cite-prefix">On 6/10/2014 4:07 AM, Edward Catmur
wrote:<br>
</div>
<blockquote
cite=3D"mid:1aaf849f-0f13-46ca-b4c6-3c6bcd695807@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Consider
a function F with two scalar results, and a function G <br>
accepting two arguments of the scalar type, where the intent
is that the <br>
results of F will be the arguments of G - in the opposite
order. I was <br>
hoping for something like:
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 G([lab:f()] lab$1, lab$0)
<br>
rather than the armwaving required to use tuples (note that I
am very <br>
much not proposing that syntax; my purpose here is to gather
suggestions <br>
for the syntax.
<br>
</blockquote>
<div><br>
</div>
<div>Three ways to write that with current syntax:</div>
<div><br>
</div>
<div>
<div class=3D"prettyprint" style=3D"border: 1px solid rgb(187,
187, 187); word-wrap: break-word; background-color: rgb(250,
250, 250);"><code class=3D"prettyprint">
<div class=3D"subprettyprint"><span style=3D"color: #008;"
class=3D"styled-by-prettify">void</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> x</s=
pan><span
style=3D"color: #660;" class=3D"styled-by-prettify">()</s=
pan><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
=C2=A0 </span><span style=3D"color: #660;"
class=3D"styled-by-prettify">[](</span><span
style=3D"color: #008;" class=3D"styled-by-prettify">auto<=
/span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> lab<=
/span><span
style=3D"color: #660;" class=3D"styled-by-prettify">)</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #008;" class=3D"styled-by-prettify">retur=
n</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> g</s=
pan><span
style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify">std</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span
style=3D"color: #008;" class=3D"styled-by-prettify">get</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify"><<=
/span><span
style=3D"color: #066;" class=3D"styled-by-prettify">1</sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">>(=
</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">lab</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">),</s=
pan><span
style=3D"color: #000;" class=3D"styled-by-prettify"> std<=
/span><span
style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span
style=3D"color: #008;" class=3D"styled-by-prettify">get</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify"><<=
/span><span
style=3D"color: #066;" class=3D"styled-by-prettify">0</sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">>(=
</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">lab</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">));</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">}(</s=
pan><span
style=3D"color: #000;" class=3D"styled-by-prettify">f</sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">());<=
/span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">}</span><span style=3D"color=
:
#000;" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #008;"
class=3D"styled-by-prettify">void</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> y</s=
pan><span
style=3D"color: #660;" class=3D"styled-by-prettify">()</s=
pan><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
=C2=A0 </span><span style=3D"color: #660;"
class=3D"styled-by-prettify">[](</span><span
style=3D"color: #008;" class=3D"styled-by-prettify">declt=
ype</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify">f</sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">())</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> lab<=
/span><span
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify">f</sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">())</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #008;" class=3D"styled-by-prettify">retur=
n</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> g</s=
pan><span
style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify">std</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span
style=3D"color: #008;" class=3D"styled-by-prettify">get</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify"><<=
/span><span
style=3D"color: #066;" class=3D"styled-by-prettify">1</sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">>(=
</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">lab</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">),</s=
pan><span
style=3D"color: #000;" class=3D"styled-by-prettify"> std<=
/span><span
style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span
style=3D"color: #008;" class=3D"styled-by-prettify">get</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify"><<=
/span><span
style=3D"color: #066;" class=3D"styled-by-prettify">0</sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">>(=
</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">lab</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">));</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">}();<=
/span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">}</span><span style=3D"color=
:
#000;" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #008;"
class=3D"styled-by-prettify">void</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> z</s=
pan><span
style=3D"color: #660;" class=3D"styled-by-prettify">()</s=
pan><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
=C2=A0 </span><span style=3D"color: #008;"
class=3D"styled-by-prettify">auto</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> lab =
</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> f</s=
pan><span
style=3D"color: #660;" class=3D"styled-by-prettify">();</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
=C2=A0 g</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">(</span><span style=3D"color=
:
#000;" class=3D"styled-by-prettify">std</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span
style=3D"color: #008;" class=3D"styled-by-prettify">get</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify"><<=
/span><span
style=3D"color: #066;" class=3D"styled-by-prettify">1</sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">>(=
</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">lab</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">),</s=
pan><span
style=3D"color: #000;" class=3D"styled-by-prettify"> std<=
/span><span
style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span
style=3D"color: #008;" class=3D"styled-by-prettify">get</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify"><<=
/span><span
style=3D"color: #066;" class=3D"styled-by-prettify">0</sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">>(=
</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">lab</=
span><span
style=3D"color: #660;" class=3D"styled-by-prettify">));</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">}</span></div>
</code></div>
<div><br>
</div>
</div>
<div>Clang compiles all three identically (with <font
face=3D"courier new, monospace">f</font> returning <font
face=3D"courier new, monospace">std::tuple<int, double></=
font>):</div>
<div><br>
</div>
<div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187,
187); word-wrap: break-word; background-color: rgb(250, 250,
250);"><code class=3D"prettyprint">
<div class=3D"subprettyprint"><span style=3D"color: #000;"
class=3D"styled-by-prettify">=C2=A0pushq </span><span
style=3D"color: #660;" class=3D"styled-by-prettify">%</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify">rax<br>
=C2=A0callq f</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">()</span><span style=3D"color:
#000;" class=3D"styled-by-prettify"><br>
=C2=A0movl </span><span style=3D"color: #660;"
class=3D"styled-by-prettify">%</span><span style=3D"color:
#000;" class=3D"styled-by-prettify">eax</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
style=3D"color: #660;" class=3D"styled-by-prettify">%</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify">edi<br>
=C2=A0popq </span><span style=3D"color: #660;"
class=3D"styled-by-prettify">%</span><span style=3D"color:
#000;" class=3D"styled-by-prettify">rax<br>
=C2=A0jmp g</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">(</span><span style=3D"color:
#008;" class=3D"styled-by-prettify">double</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">,</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span
style=3D"color: #008;" class=3D"styled-by-prettify">int</sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">)</span=
><span
style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0=
=C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</span><span style=3D"col=
or: #800;"
class=3D"styled-by-prettify"># TAILCALL</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span></div>
</code></div>
<div><br>
</div>
<br>
</div>
</blockquote>
<snip><br>
<br>
Thank you; this is much better than I had seen before. If the
compiler is as effective on other cases then it lays my concerns
about performance to rest.<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------020100010009070906070102--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 10 Jun 2014 12:59:08 -0400
Raw View
On 2014-06-10 06:47, Ville Voutilainen wrote:
> Tuples are less than convenient due to having to use
> std::get<N>, which isn't very readable.
It occurred to me... syntactically, is there a reason why it would be
hard to implement:
std::tuple<int, double, char, long> a;
auto a1 = a<1>; // a1 has type double
auto a3 = a<-1>; // a3 has type long
auto ax = a<2:> // ax has type tuple<char, long>
auto ay = a<:2,3> // ay has type tuple<int, double, long>
....? (Similar for other Pythonic slicing.)
IOW, t<n> where 't' is a tuple would be shorthand for std::get<n>(t).
Then also allow recomposing tuples with slicing and multiple slicing
arguments using ','.
This, plus tuple argument unpacking, would solve the problem of passing
partial or out-of-order return values as arguments:
g(<*>(f()<1,0>));
(Using '<*>' this time for tuple-to-argument unpacking, as it's less
ambiguous than just '*' to tell the compiler that something other than
'operator*' is going on.)
> I should probably mention that if std::expected lands into C++,
> there's yet fewer cases where I'd ever resort to returning multiple
> values.
Of course, I'd claim that std::expected *is* a multiple return value
:-). So is std::pair, std::tuple, structs, etc. :-). Which is why I
don't understand why there is such an issue here; we already *have*
multiple return values. If Ivan's API can't deal with them in a
reasonable manner, that's not the language's fault.
(Though, that said, previous comments suggest that maybe there *is* a
problem with std::tuple being treated as an aggregate. If so, that
possibly *would* be the language's fault, assuming it isn't just a bug
in the library implementation.)
I do think there is room to have better syntactic sugar, e.g. '<int,
int> foo();' as shorthand for 'std::tuple<int, int> foo();', tuple
unpacking, and possible tuple slicing as suggested above.
And possibly even at some point '<int...>' as shorthand for some
yet-unknown mechanism for returning a VLA of 'int'.
--
Matthew
--
---
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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 10 Jun 2014 20:58:17 +0300
Raw View
On 10 June 2014 19:59, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
>> I should probably mention that if std::expected lands into C++,
>> there's yet fewer cases where I'd ever resort to returning multiple
>> values.
> Of course, I'd claim that std::expected *is* a multiple return value
> :-). So is std::pair, std::tuple, structs, etc. :-). Which is why I
> don't understand why there is such an issue here; we already *have*
> multiple return values. If Ivan's API can't deal with them in a
> reasonable manner, that's not the language's fault.
I think we agree there. I see very little need for core language
multiple-return-values.
> I do think there is room to have better syntactic sugar, e.g. '<int,
> int> foo();' as shorthand for 'std::tuple<int, int> foo();', tuple
> unpacking, and possible tuple slicing as suggested above.
If someone can come up with a decent proposal that assures there are no
specification or implementation difficulties with such things, I'm sure the
committee will listen. I doubt it will be so easy to either implement or
specify, and I don't think tuples deserve such special syntax that stands out
from what we already have.
--
---
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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 11 Jun 2014 15:55:08 +0200
Raw View
Em ter 10 jun 2014, =E0s 02:30:10, Ivan Godard escreveu:
> On 6/10/2014 1:42 AM, Thiago Macieira wrote:
> > Did you search the archives?
>=20
> No. I have no idea where the archives are. I did ask for pointers, if
> you recall. I came here after finding nothing new to me in a Google of
> "multi-result functions in C++", expecting that I might find better
> search keys here, or other useful pointers.
This is a mailing list. All public mailing lists have archives, probably=20
multiple ones, on the internet. Etiquette rules for mailing lists say that =
you=20
should always consult the archive to see if your question has been answered=
=20
before.
Maybe you didn't know it. Now you do. The link to the mailing list's websit=
e=20
is in the footer of every single email you receive. And it's indexed by=20
Google.
> > DId you see the email that pointed out to the
> > paper on this exact subject?
>=20
> No. Whose email was it? Can you repeat the pointer? Pretty much
> everything I have seen in postings so far has appeared to be about the
> tuple solution, but I don't need info about that.
Thomas Braxton's email dated Mon, 9 Jun 2014 23:57:35 -0500 (Message-Id=20
CAPHJ0U03X=3DWYR6mHtEApK8Khq09nEY4Z6CTp_20E5gEJjZb-yg@mail.gmail.com). He w=
as=20
simply giving you the pointer to the N4025 paper.
> > >From reading all the emails in this thread, it seems that you got off =
on
> > >the>=20
> > wrong foot by trying to make something that is special for your
> > architecture. You can bet that we 99% of the people here couldn't care
> > less about your architecture. We're not stake holders in it -- and many
> > of us, including me, are actually stakeholders in competitors.
>=20
> Well, in all innocence I was trying to motivate why I showed up a
> stranger on this board, admittedly unfamiliar with its denizens and
> conventions. I thought providing the context was a courtesy, but it
> appears to have been seen as an attack.
Context is good, but it was not perceived as context. It was perceived most=
ly=20
as the motivation/agenda and by setting your hardware apart. You can=20
understand that we don't really care to help make your hardware apart from=
=20
ours...
What's more, tying language features to hardware capabilities is really=20
frowned upon. That's a recipe for getting something rejected by the standar=
ds=20
committee. Instead, like I said before, you should approach this from the "=
how=20
do I make the language better" point of view. What is the problem you're=20
trying to solve? Are you sure that it requires a language extension to do i=
t?=20
Can't we find a better solution in different ways?
And by the way, when calling conventions are involved, the C++ language=20
follows in close lockstep with C, so you should also approach WG14 about th=
is.
> It had been my understanding that a common path for additions to the
> standard was for an interested party with an idea would implement the
> idea as an extension in one of the widely used compilers (or boost for
> something that could be done as a library). After experience with the
> implementation, the community would then reject the idea, accept it, or
> improve it, and eventually someone (possibly not the original
> implementer) would draft it up as a proposal with all the proper
> phrasing, and eventually, if not rejected, the idea would be enshrined.
Correct.
> As we will be porting the compilers anyway, it seemed not much more work
> to see what we could come up with and incorporate it; if the idea turned
> out to be sound then all benefit, and if not then the experience with
> implementation and use should soon reveal that. I even naively thought
> that the community here would be happy that someone was willing to pay
> for the work involved in such exploration.
Also true. However, you are talking about a subject that has been discussed=
=20
before, with very different solutions from what you were proposing. If you =
add=20
that to the misunderstanding on the context/motivation, it sounded like you=
=20
were just trying to push a particular agenda, as opposed to improving C++ f=
or=20
everyone.
> > Instead, the discussion should have focused only and exclusively on
> > multiple result. See also the threads "C++ named tuple", "Unpacking
> > syntax for tuples using auto", and a few others.
>=20
> I shall, although the titles suggest more on tuples. Can you expand on
> "a few others"?
Not really. I do remember lengthy discussions and those are the two I could=
=20
easily find. And since this seems to be a particularly popular topic, there=
may=20
have been discussions before my joining this mailing list and in the standa=
rds=20
committee itself. So I think there's more to be read, but I can't be sure.
> > So, no, the status is not that we think the current solution is perfect=
..
> > Far from it. There's a lot of room to improve and you can and should
> > contribute to it.
>=20
> Begging your pardon, but why would I want to after such a welcome? At
From our point of view, we did everything right and the one at fault was yo=
u.=20
In any case, Internet requires thick skin. So I am trying right now to clea=
r=20
up the misunderstanding so we can work together.
> least in the circles that I do contribute to, people sometimes tell me
> my stuff won't work, and people sometimes tell me it could be done
> better, and people sometimes tell me the goals and approach are
> wrong-headed, and people sometimes tell me I'm a newbie and should be
> quiet until I learn more, but they don't call me a fraud.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=20
---=20
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 e=
mail 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-proposa=
ls/.
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 11 Jun 2014 14:22:24 -0400
Raw View
--001a1133d1e29f494504fb938692
Content-Type: text/plain; charset=UTF-8
On Wed, Jun 11, 2014 at 9:55 AM, Thiago Macieira <thiago@macieira.org>
wrote:
> From our point of view, we did everything right and the one at fault was
> you.
>
I don't know, I think some comments went too far.
> In any case, Internet requires thick skin. So I am trying right now to
> clear
> up the misunderstanding so we can work together.
>
>
How about we just start over.
Basically:
- new hardware. OK, interesting, but whatever - it needs to be a useful
language feature regardless of hardware.
- multiple return values: discussed in the past, some want it, some don't
think it is worth it
note the "worth" part - adding language (not just library) to the standard
is very costly in terms of time (of committee members) and resulting
complexity - the language is too complicated already.
You might go so far to say "we almost all want it, we almost all don't
think it is worth it".
Personally, I'd like it. I'd also like { a, b } to be a tuple (or
convertible to tuple), basically. For return, I would definitely head down
the road of
{ a, b } = f();
Is it worth it? I could paraphrase Ville as "I already have 7 workarounds,
I don't need it". But to me that is a sign of needing it.
!! But only if it is elegant !!
And that's the hard part. I have no references to previous discussions,
but it has been tackled (unsuccessfully) in the past.
Also, it isn't a small feature - it isn't just return. It is also packing
and unpacking, declaration, etc. It touches so many parts of the language.
So I might paraphrase Ville slightly differently "I already have 7
workarounds, I don't need it... that badly".
Tony
--
---
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/.
--001a1133d1e29f494504fb938692
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Jun 11, 2014 at 9:55 AM, Thiago Macieira <span dir=3D"ltr">=
<<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieir=
a.org</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">From our point of view, w=
e did everything right and the one at fault was you.<br></blockquote><div><=
br>
</div><div>I don't know, I think some comments went too far.<br>=C2=A0<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In any case, Internet requires thick skin. So I am trying right now to clea=
r<br>
up the misunderstanding so we can work together.<br>
<div class=3D"im"><br></div></blockquote></div><br></div><div class=3D"gmai=
l_extra">How about we just start over.<br><br>Basically:<br><br></div><div =
class=3D"gmail_extra">- new hardware. OK, interesting, but whatever - it ne=
eds to be a useful language feature regardless of hardware.<br>
</div><div class=3D"gmail_extra">- multiple return values: discussed in the=
past, some want it, some don't think it is worth it<br></div><div clas=
s=3D"gmail_extra"><br>note the "worth" part - adding language (no=
t just library) to the standard is very costly in terms of time (of committ=
ee members) and resulting complexity - the language is too complicated alre=
ady.<br>
<br></div><div class=3D"gmail_extra">You might go so far to say "we al=
most all want it, we almost all don't think it is worth it".<br></=
div><div class=3D"gmail_extra"><br>Personally, I'd like it.=C2=A0 I'=
;d also like { a, b } to be a tuple (or convertible to tuple), basically.=
=C2=A0 For return, I would definitely head down the road of<br>
<br></div><div class=3D"gmail_extra">=C2=A0=C2=A0=C2=A0 { a, b } =3D f();<b=
r><br></div><div class=3D"gmail_extra">Is it worth it?=C2=A0 I could paraph=
rase Ville as "I already have 7 workarounds, I don't need it"=
..=C2=A0 But to me that is a sign of needing it.<br>
<br></div><div class=3D"gmail_extra">!! But only if it is elegant !!<br><br=
></div><div class=3D"gmail_extra">And that's the hard part.=C2=A0 I hav=
e no references to previous discussions, but it has been tackled (unsuccess=
fully) in the past.<br>
<br></div><div class=3D"gmail_extra">Also, it isn't a small feature - i=
t isn't just return.=C2=A0 It is also packing and unpacking, declaratio=
n, etc.=C2=A0 It touches so many parts of the language.<br><br></div><div c=
lass=3D"gmail_extra">
So I might paraphrase Ville slightly differently "I already have 7 wor=
karounds, I don't need it... that badly".<br><br></div><div class=
=3D"gmail_extra">Tony<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a1133d1e29f494504fb938692--
.
Author: Ivan Godard <ivan@MillComputing.com>
Date: Wed, 11 Jun 2014 12:03:15 -0700
Raw View
This is a multi-part message in MIME format.
--------------080707090709020604040305
Content-Type: text/plain; charset=UTF-8; format=flowed
On 6/11/2014 11:22 AM, Tony V E wrote:
>
>
>
> On Wed, Jun 11, 2014 at 9:55 AM, Thiago Macieira <thiago@macieira.org
> <mailto:thiago@macieira.org>> wrote:
>
> From our point of view, we did everything right and the one at
> fault was you.
>
>
> I don't know, I think some comments went too far.
>
> In any case, Internet requires thick skin. So I am trying right
> now to clear
> up the misunderstanding so we can work together.
>
>
> How about we just start over.
<snip>
>
> So I might paraphrase Ville slightly differently "I already have 7
> workarounds, I don't need it... that badly".
>
Yes, I have understood that the answer to my question "are there better
ideas around that just need an implementation for experience" was: no.
Not the answer I was hoping for, but I am answered.
> Tony
>
And I thank you for your gracious answer to a newbie. I'll go away now.
But before I do, I'll comment on the line from Thiago that you quote:
"In any case, Internet requires thick skin".
Why should it?
I participate in many boards, forums, and standards groups, and each
such group has a "feel", a character, that is as unmistakable as the
feel you get walking into a strange bar. Some bars require a thick skin
- or an exit to a different watering hole where the beer doesn't come
with testosterone chasers.
Ivan
--
---
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/.
--------------080707090709020604040305
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<br>
<div class=3D"moz-cite-prefix">On 6/11/2014 11:22 AM, Tony V E wrote:<b=
r>
</div>
<blockquote
cite=3D"mid:CAOHCbivEuESpMA=3D-WbcoODeOUjYXWC_iEKkY0YFAbYwF9KLRhg@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr"><br>
<div class=3D"gmail_extra"><br>
<br>
<div class=3D"gmail_quote">On Wed, Jun 11, 2014 at 9:55 AM,
Thiago Macieira <span dir=3D"ltr"><<a
moz-do-not-send=3D"true" href=3D"mailto:thiago@macieira.org=
"
target=3D"_blank">thiago@macieira.org</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">From our point of view,
we did everything right and the one at fault was you.<br>
</blockquote>
<div><br>
</div>
<div>I don't know, I think some comments went too far.<br>
=C2=A0<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
In any case, Internet requires thick skin. So I am trying
right now to clear<br>
up the misunderstanding so we can work together.<br>
<div class=3D"im"><br>
</div>
</blockquote>
</div>
<br>
</div>
<div class=3D"gmail_extra">How about we just start over.</div>
</div>
</blockquote>
<div dir=3D"ltr">
<div class=3D"gmail_extra"><snip><br>
</div>
</div>
<br>
<blockquote
cite=3D"mid:CAOHCbivEuESpMA=3D-WbcoODeOUjYXWC_iEKkY0YFAbYwF9KLRhg@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra"><br>
</div>
<div class=3D"gmail_extra">
So I might paraphrase Ville slightly differently "I already
have 7 workarounds, I don't need it... that badly".<br>
<br>
</div>
</div>
</blockquote>
Yes, I have understood that the answer to my question "are there
better ideas around that just need an implementation for experience"
was: no. Not the answer I was hoping for, but I am answered.<br>
<blockquote
cite=3D"mid:CAOHCbivEuESpMA=3D-WbcoODeOUjYXWC_iEKkY0YFAbYwF9KLRhg@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">Tony<br>
</div>
</div>
<br>
</blockquote>
And I thank you for your gracious answer to a newbie. I'll go away
now.<br>
<br>
But before I do, I'll comment on the line from Thiago that you
quote: "In any case, Internet requires thick skin". <br>
<br>
Why should it?<br>
<br>
I participate in many boards, forums, and standards groups, and each
such group has a "feel", a character, that is as unmistakable as the
feel you get walking into a strange bar. Some bars require a thick
skin - or an exit to a different watering hole where the beer
doesn't come with testosterone chasers.<br>
<br>
Ivan<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--------------080707090709020604040305--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 11 Jun 2014 22:42:34 +0300
Raw View
On 11 June 2014 21:22, Tony V E <tvaneerd@gmail.com> wrote:
> Also, it isn't a small feature - it isn't just return. It is also packing
> and unpacking, declaration, etc. It touches so many parts of the language.
The unpacking syntax you showed as an example also nicely complicates
the implementation for handling declarations. Having worked on that, I may
be personally biased against making it any more complicated than it already
is, unless there are very, very strong reasons for it. Multiple return values
do not pass that bar for me.
> So I might paraphrase Ville slightly differently "I already have 7
> workarounds, I don't need it... that badly".
I don't have 7 work-arounds, I have 7 alternative ways to solve the problem,
one of which (a named struct with named members, any invariants I choose,
and any semantics I want to express) is vastly superior to multiple return
values. The only case where I've found a real need for multiple return
values and
especially the unpacking of those into single variables is quick prototypes.
Well, C++ can't be a language for everything; perhaps it's sub-optimal for
quick prototypes. I can't say that's a problem for me.
--
---
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/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 11 Jun 2014 13:39:06 -0700
Raw View
--bcaec501629b86cc4704fb956fad
Content-Type: text/plain; charset=UTF-8
On Wed, Jun 11, 2014 at 12:03 PM, Ivan Godard <ivan@millcomputing.com>
wrote:
>
> On 6/11/2014 11:22 AM, Tony V E wrote:
>
>
>
>
> On Wed, Jun 11, 2014 at 9:55 AM, Thiago Macieira <thiago@macieira.org>
> wrote:
>
>> From our point of view, we did everything right and the one at fault was
>> you.
>>
>
> I don't know, I think some comments went too far.
>
>
>> In any case, Internet requires thick skin. So I am trying right now to
>> clear
>> up the misunderstanding so we can work together.
>>
>>
> How about we just start over.
>
> <snip>
>
>
> So I might paraphrase Ville slightly differently "I already have 7
> workarounds, I don't need it... that badly".
>
> Yes, I have understood that the answer to my question "are there better
> ideas around that just need an implementation for experience" was: no. Not
> the answer I was hoping for, but I am answered.
>
> Tony
>
> And I thank you for your gracious answer to a newbie. I'll go away now.
>
> But before I do, I'll comment on the line from Thiago that you quote: "In
> any case, Internet requires thick skin".
>
> Why should it?
>
> I participate in many boards, forums, and standards groups, and each such
> group has a "feel", a character, that is as unmistakable as the feel you
> get walking into a strange bar. Some bars require a thick skin - or an exit
> to a different watering hole where the beer doesn't come with testosterone
> chasers.
>
+1
I don't think it's fair to blame a bad experience in a particular group on
"the internet"; messages come from people. If useful contributors are being
discouraged from participating due to aggressive or antagonistic responses
here, that is a problem that we should be thinking about how to address.
--
---
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/.
--bcaec501629b86cc4704fb956fad
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jun 11, 2014 at 12:03 PM, Ivan Godard <span dir=3D"ltr"><<a href=3D"=
mailto:ivan@millcomputing.com" target=3D"_blank">ivan@millcomputing.com</a>=
></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><div class=3D"">
<br>
<div>On 6/11/2014 11:22 AM, Tony V E wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<div class=3D"gmail_extra"><br>
<br>
<div class=3D"gmail_quote">On Wed, Jun 11, 2014 at 9:55 AM,
Thiago Macieira <span dir=3D"ltr"><<a href=3D"mailto:thiago@=
macieira.org" target=3D"_blank">thiago@macieira.org</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">From our poin=
t of view,
we did everything right and the one at fault was you.<br>
</blockquote>
<div><br>
</div>
<div>I don't know, I think some comments went too far.<br>
=C2=A0<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In any case, Internet requires thick skin. So I am trying
right now to clear<br>
up the misunderstanding so we can work together.<br>
<div><br>
</div>
</blockquote>
</div>
<br>
</div>
<div class=3D"gmail_extra">How about we just start over.</div>
</div>
</blockquote>
</div><div dir=3D"ltr">
<div class=3D"gmail_extra"><snip><br>
</div>
</div><div class=3D"">
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra"><br>
</div>
<div class=3D"gmail_extra">
So I might paraphrase Ville slightly differently "I already
have 7 workarounds, I don't need it... that badly".<br>
<br>
</div>
</div>
</blockquote></div>
Yes, I have understood that the answer to my question "are there
better ideas around that just need an implementation for experience&quo=
t;
was: no. Not the answer I was hoping for, but I am answered.<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div class=3D"gmail_extra">Tony<br>
</div>
</div>
<br>
</blockquote>
And I thank you for your gracious answer to a newbie. I'll go away
now.<br>
<br>
But before I do, I'll comment on the line from Thiago that you
quote: "In any case, Internet requires thick skin". <br>
<br>
Why should it?<br>
<br>
I participate in many boards, forums, and standards groups, and each
such group has a "feel", a character, that is as unmistakable=
as the
feel you get walking into a strange bar. Some bars require a thick
skin - or an exit to a different watering hole where the beer
doesn't come with testosterone chasers.</div></blockquote><div><br>=
</div><div>+1</div><div><br></div><div>I don't think it's fair to b=
lame a bad experience in a particular group on "the internet"; me=
ssages come from people. If useful contributors are being discouraged from =
participating due to aggressive or antagonistic responses here, that is a p=
roblem that we should be thinking about how to address.</div>
</div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--bcaec501629b86cc4704fb956fad--
.
Author: gmisocpp@gmail.com
Date: Wed, 11 Jun 2014 19:09:16 -0700 (PDT)
Raw View
------=_Part_2115_19345241.1402538956118
Content-Type: text/plain; charset=UTF-8
On Thursday, June 12, 2014 8:39:07 AM UTC+12, Richard Smith wrote:
>
> On Wed, Jun 11, 2014 at 12:03 PM, Ivan Godard <iv...@millcomputing.com
> <javascript:>> wrote:
>
>>
>> On 6/11/2014 11:22 AM, Tony V E wrote:
>>
>>
>>
>>
>> On Wed, Jun 11, 2014 at 9:55 AM, Thiago Macieira <thi...@macieira.org
>> <javascript:>> wrote:
>>
>>> From our point of view, we did everything right and the one at fault was
>>> you.
>>>
>>
>> I don't know, I think some comments went too far.
>>
>>
>>> In any case, Internet requires thick skin. So I am trying right now to
>>> clear
>>> up the misunderstanding so we can work together.
>>>
>>>
>> How about we just start over.
>>
>> <snip>
>>
>>
>> So I might paraphrase Ville slightly differently "I already have 7
>> workarounds, I don't need it... that badly".
>>
>> Yes, I have understood that the answer to my question "are there
>> better ideas around that just need an implementation for experience" was:
>> no. Not the answer I was hoping for, but I am answered.
>>
>> Tony
>>
>> And I thank you for your gracious answer to a newbie. I'll go away now.
>>
>> But before I do, I'll comment on the line from Thiago that you quote: "In
>> any case, Internet requires thick skin".
>>
>> Why should it?
>>
>> I participate in many boards, forums, and standards groups, and each such
>> group has a "feel", a character, that is as unmistakable as the feel you
>> get walking into a strange bar. Some bars require a thick skin - or an exit
>> to a different watering hole where the beer doesn't come with testosterone
>> chasers.
>>
>
> +1
>
> I don't think it's fair to blame a bad experience in a particular group on
> "the internet"; messages come from people. If useful contributors are being
> discouraged from participating due to aggressive or antagonistic responses
> here, that is a problem that we should be thinking about how to address.
>
I think this particular thread just got off to a bad start and isn't
typical of the more general "problem" I think this forum has.
I watched this thread as it unfolded and the initial post appeared to me
(wrongly as it turns out) to be some kind of "scam/troll" post. I found the
idea that somebody was working on a CPU that was specializing in the
particular "problem" as highly unlikely. So that made me kind of
sceptical if the post was real and I wasn't sure if to take it seriously or
not.
But what confirmed that misunderstanding was some of the phrasing used by
the poster, which seemed to be pretty dislikeable. In particular, it
was the part in the conversation where the poster appeared to be
effectively saying "I only care about my cpu and nothing else, yet I still
expect you to help me with my niche CPU and extend C++ to support it
anyway". As in, "I don't care about anything else, but you should.".
Given that this is the hello, "iso" cpp forum, a statement like
that to this forum, of all forums, would seem to me like being the surest
way to be shown the door!
Standardization and niche aren't instant easy bed fellows I would think.
That doesn't mean one can't help though, but the way things initially came
across, it didn't make it look like help was warranted.
I hope the poster will take that comment to heart and not be offended by
it. I hope that explains to the OP, why things might have started off
badly, even if it doesn't fully justify all of how things went.
So overall, given the circumstance, I'm not entirely sure how this
particular thread could have played out differently. I personally can see
why some of the apparent hostility was drawn even if I do think it would
have been better if it hadn't happened.
But things did settle down eventually. It just took a few posts to realise
the OP is a serious person trying to do something serious, if unusual (to
me) and "we" got the right answer in the end which is Tony's conclusion:
Misunderstanding, start again.
But as a new-ish person myself here, I agree with Richard's +1, that seems
to allude to their still being a general problem even if this particular
thread doesn't directly demonstrate it (IMHO).
To avoid talking too abstractly, Ville makes a great example of the
"problem", or not, with this forum. Ville is usually 95% right, in my
opinion, if not higher. Many of the ideas he's shot down, I initially
thought had potential, but when I went away and tried to advance them more,
they just weren't that great. Ville was right. He usually is.
But I wonder, for the experts (which probably means most people on this
site compared to the outside world at large), isn't it a case of, "with
great power comes great responsibility" and that means entertaining mere
mortals (more) why they argue a bad idea badly?
That will make this site more like Reddit, which I would say is bad, but I
actually spend as much time on Reddit reading things as I do here (and it's
increasing). I can't say the standard there is higher, but sometimes I can
say the "feel" is.
I wouldn't want to be without either site, but if C++ is to start growing
again (assuming it has stalled or shrunk), I can only see that being
achieved through everybody being more welcoming to new (aka not new) *bad*
ideas - to encourage that interest and growth and tomorrows experts.
If the best of both worlds could be achieved, would that be great?
Anyway, you have my great idea on how to make this site more approachable.
Will that make it better, I don't know, but there's one way to find out.
Let the arrows begin! :)
PS
Yes, of course I shoot arrows too on my bad days; I no doubt will continue
to do so too.
--
---
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_2115_19345241.1402538956118
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, June 12, 2014 8:39:07 AM UTC+12, Rich=
ard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px =
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border=
-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><div cla=
ss=3D"gmail_quote">On Wed, Jun 11, 2014 at 12:03 PM, Ivan Godard <span dir=
=3D"ltr"><<a onmousedown=3D"this.href=3D'javascript:';return true;" oncl=
ick=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"6Z54D6GzE8sJ">iv...@millcomputing.com<=
/a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; paddi=
ng-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px=
; border-left-style: solid;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF"><div>
<br>
<div>On 6/11/2014 11:22 AM, Tony V E wrote:<br>
</div>
<blockquote type=3D"cite">
<div dir=3D"ltr"><br>
<div><br>
<br>
<div class=3D"gmail_quote">On Wed, Jun 11, 2014 at 9:55 AM,
Thiago Macieira <span dir=3D"ltr"><<a onmousedown=3D"this.hr=
ef=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';retur=
n true;" href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"6Z=
54D6GzE8sJ">thi...@macieira.org</a>></span>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;">From our point of view,
we did everything right and the one at fault was you.<br>
</blockquote>
<div><br>
</div>
<div>I don't know, I think some comments went too far.<br>
<br>
</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;">
In any case, Internet requires thick skin. So I am trying
right now to clear<br>
up the misunderstanding so we can work together.<br>
<div><br>
</div>
</blockquote>
</div>
<br>
</div>
<div>How about we just start over.</div>
</div>
</blockquote>
</div><div dir=3D"ltr">
<div><snip><br>
</div>
</div><div>
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div><br>
</div>
<div>
So I might paraphrase Ville slightly differently "I already
have 7 workarounds, I don't need it... that badly".<br>
<br>
</div>
</div>
</blockquote></div>
Yes, I have understood that the answer to my question "are there
better ideas around that just need an implementation for experience"
was: no. Not the answer I was hoping for, but I am answered.<br>
<blockquote type=3D"cite">
<div dir=3D"ltr">
<div>Tony<br>
</div>
</div>
<br>
</blockquote>
And I thank you for your gracious answer to a newbie. I'll go away
now.<br>
<br>
But before I do, I'll comment on the line from Thiago that you
quote: "In any case, Internet requires thick skin". <br>
<br>
Why should it?<br>
<br>
I participate in many boards, forums, and standards groups, and each
such group has a "feel", a character, that is as unmistakable as the
feel you get walking into a strange bar. Some bars require a thick
skin - or an exit to a different watering hole where the beer
doesn't come with testosterone chasers.</div></blockquote><div><br></di=
v><div>+1</div><div><br></div><div>I don't think it's fair to blame a bad e=
xperience in a particular group on "the internet"; messages come from peopl=
e. If useful contributors are being discouraged from participating due to a=
ggressive or antagonistic responses here, that is a problem that we should =
be thinking about how to address.</div></div></div></div></blockquote><div>=
<br></div><div>I think this particular thread just got off to a bad start a=
nd isn't typical of the more general "problem" I think this forum =
;has.</div><div><br></div><div>I watched this thread as it unfolded and&nbs=
p;the initial post appeared to me (wrongly as it turns out) to be=
some kind of "scam/troll" post. I found the idea that somebody was wo=
rking on a CPU that was specializing in the particular "problem" as hi=
ghly unlikely. So that made me kind of sceptical if the post =
;was real and I wasn't sure if to take it seriously or =
not.</div><div><br></div><div>But what confirmed that misunderstanding =
;was some of the phrasing used by the poster, which seemed t=
o be pretty dislikeable. In particular, it was the part in t=
he conversation where the poster appeared to be effectively saying "I =
only care about my cpu and nothing else, yet I still expect you t=
o help me with my niche CPU and extend C++ to support&n=
bsp;it anyway". As in, "I don't care about anything else, but you should.".=
</div><div><br></div><div>Given that this is the hello, "iso" cpp foru=
m, a statement like that to this forum, of all forums, would seem=
to me like being the surest way to be shown the door! </div><div><br>=
</div><div>Standardization and niche aren't instant easy bed fellows I=
would think. That doesn't mean one can't help though, but the way things i=
nitially came across, it didn't make it look like help was warranted.</div>=
<div><br></div><div><div>I hope the poster will take that comment to h=
eart and not be offended by it. I hope that explains to the OP, why things =
might have started off badly, even if it doesn't fully justify all of =
how things went.</div></div><div><br></div><div><div>So overall, given the =
circumstance, I'm not entirely sure how this particular thread could have p=
layed out differently. I personally can see why some of the appar=
ent hostility was drawn even if I do think it would have been bet=
ter if it hadn't happened.</div><div><br></div><div>But things did set=
tle down eventually. It just took a few posts to r=
ealise the OP is a serious person trying to do something serious,=
if unusual (to me) and "we" got the right answer in the end which is&=
nbsp;Tony's conclusion: Misunderstanding, start again.</div><div><br></div>=
</div><div>But as a new-ish person myself here, I agree with Richard's=
+1, that seems to allude to their still being a general problem even =
if this particular thread doesn't directly demonstrate it (IMHO).</div><div=
><br></div><div>To avoid talking too abstractly, Ville makes a gr=
eat example of the "problem", or not, with this forum. Ville=
is usually 95% right, in my opinion, if not higher. Many of the =
ideas he's shot down, I initially thought had potential, but when=
I went away and tried to advance them more, they just weren't that gr=
eat. Ville was right. He usually is.</div><div><br></div><div>But I wonder,=
for the experts (which probably means most people on this site c=
ompared to the outside world at large), isn't it a case of, "with great pow=
er comes great responsibility" and that means entertaining mere mortal=
s (more) why they argue a bad idea badly?</div><div><br></div><div>That wil=
l make this site more like Reddit, which I would say is bad, but I actually=
spend as much time on Reddit reading things as I do here (and it's increas=
ing). I can't say the standard there is higher, but sometimes I can sa=
y the "feel" is.</div><div><br></div><div><div>I wouldn't want to be withou=
t either site, but if C++ is to start growing again (assuming it has stalle=
d or shrunk), I can only see that being achieved through everybody bei=
ng more welcoming to new (aka not new) *bad* ideas - to enco=
urage that interest and growth and tomorrows experts.</div><div><br></div><=
/div><div>If the best of both worlds could be achieved, would that&nbs=
p;be great?</div><div><br></div><div>Anyway, you have my great idea on how =
to make this site more approachable. Will that make it better, I don't =
; know, but there's one way to find out.</div><div><br></div><div>Let the a=
rrows begin! :)</div><div><br></div><div>PS</div><div>Yes, of course I shoo=
t arrows too on my bad days; I no doubt will continue to do so too.</d=
iv></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_2115_19345241.1402538956118--
.
Author: morwenn29@gmail.com
Date: Thu, 12 Jun 2014 00:48:23 -0700 (PDT)
Raw View
------=_Part_3681_9172805.1402559304028
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le mercredi 11 juin 2014 21:42:35 UTC+2, Ville Voutilainen a =C3=A9crit :
>
> I don't have 7 work-arounds, I have 7 alternative ways to solve the=20
> problem,=20
> one of which (a named struct with named members, any invariants I choose,=
=20
> and any semantics I want to express) is vastly superior to multiple retur=
n=20
> values. The only case where I've found a real need for multiple return=20
> values and=20
> especially the unpacking of those into single variables is quick=20
> prototypes.=20
> Well, C++ can't be a language for everything; perhaps it's sub-optimal fo=
r=20
> quick prototypes. I can't say that's a problem for me.=20
>
There is another area where I often want multiple return values or tuple
unpacking. It is when the returned values cannot be "named" but are not
a "collection" of values either. It often happens in maths. When I write a
function to solve a quadratic equation, I want it to return the two=20
solutions,
but the return values are nothing more than "two solutions". They don't nee=
d
a name of their own. So I return a std::pair or a std::array and then use
std::get when I want to use the values. But it would be somehow cleaner if
the values could be automatically unpacked in new variables without having
to pass by a pair/tuple/array.
But these are the only times where I "strongly" want such a feature. Most
of the time, I find it neater to use structures with named values.
--=20
---=20
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 e=
mail 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-proposa=
ls/.
------=_Part_3681_9172805.1402559304028
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Le mercredi 11 juin 2014 21:42:35 UTC+2, Ville Voutilainen=
a =C3=A9crit :<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I don't ha=
ve 7 work-arounds, I have 7 alternative ways to solve the problem,
<br>one of which (a named struct with named members, any invariants I choos=
e,
<br>and any semantics I want to express) is vastly superior to multiple ret=
urn
<br>values. The only case where I've found a real need for multiple return
<br>values and
<br>especially the unpacking of those into single variables is quick protot=
ypes.
<br>Well, C++ can't be a language for everything; perhaps it's sub-optimal =
for
<br>quick prototypes. I can't say that's a problem for me.
<br></blockquote><div><br>There is another area where I often want multiple=
return values or tuple<br>unpacking. It is when the returned values cannot=
be "named" but are not<br>a "collection" of values either. It often happen=
s in maths. When I write a<br>function to solve a quadratic equation, I wan=
t it to return the two solutions,<br>but the return values are nothing more=
than "two solutions". They don't need<br>a name of their own. So I return =
a std::pair or a std::array and then use<br>std::get when I want to use the=
values. But it would be somehow cleaner if<br>the values could be automati=
cally unpacked in new variables without having<br>to pass by a pair/tuple/a=
rray.<br><br>But these are the only times where I "strongly" want such a fe=
ature. Most<br>of the time, I find it neater to use structures with named v=
alues.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_3681_9172805.1402559304028--
.