<div class="gmail_quote">On 4 January 2012 16:23, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:SeeWebsiteForEmail@erdani.org">SeeWebsiteForEmail@erdani.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 1/4/12 2:36 AM, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regardless, I'd like to put a strong +1 towards proper multiple return<br>
values. The point is NOT just to have the syntactical feature (ie.<br>
struct return value semantics via tuples). The point is a language<br>
guarantee that the architecture will do its best job to return each<br>
value in consecutive registers OF ITS OWN TYPE, avoiding<br>
allocation&writing to the stack. This is a common problem in C where the<br>
only solution is to make functions inline or pay the cost of hitting the<br>
stack (LHS hazard, very expensive on many RISC architectures).<br>
It would lead to many optimisations in lots of code in my experience.<br>
</blockquote>
<br></div>
Why make those optimizations only for multiple return values and not for every single returned structure?</blockquote><div><br></div><div>I think multiple return values and returning a struct (tuple) are fundamentally different things...</div>
<div>Multiple return values are just that, and it implies nothing about the arrangement/'structure' of those values, or how/where they are stored.. they are simply returned in their respective register types.</div>
<div><br></div><div>A struct (tuple) on the other hand must be expected that it has some 'structure', the layout is known, addressable, and you can perform memory manipulation on it.</div><div>I can't imagine any situation where returning a struct could NOT be required to reserve stack space for the struct in the appropriate layout, and results written, even if they were also returned in appropriate registers...</div>
<div>Implementing multiple return values seems far simpler and more elegant, not to mention, more predictable and intuitive in terms of ABI and register usage. Surely it would be easier/faster to implement, and I'd argue the result would be more 'proper'...</div>
</div>