<div class="gmail_quote">On 11 March 2012 03:45, Robert Jacques <span dir="ltr"><<a href="mailto:sandford@jhu.edu">sandford@jhu.edu</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 Sat, 10 Mar 2012 19:27:05 -0600, Manu <<a href="mailto:turkeyman@gmail.com" target="_blank">turkeyman@gmail.com</a>> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 11 March 2012 00:25, Sean Cavanaugh <<a href="mailto:WorksOnMyMachine@gmail.com" target="_blank">WorksOnMyMachine@gmail.com</a>> wrote:<br>
<br>
</div><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 3/10/2012 4:37 AM, Manu wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If I pass a structure TO a function by value, I know what happens, a<br>
copy is written to the stack which the function expects to find there.<br>
<br>
</blockquote>
<br>
This is only true if the compiler is forced to use the ABI, when inlining<br>
is impossible, or the type being passed is too complex. Structs of pods,<br>
most compilers do magical things to provided you don't actively work<br>
against the code gen (virtual methods, dllexports etc), too many separate<br>
.obj units in C++ etc.<br>
<br>
</blockquote>
<br></div></div><div class="im">
Talking about the typical case here, obviously not inlined, calling through<br>
the ABI, struct may be simple, just 2-3 values, can you show me a case<br>
where C++ is able to to anything particularly fancy?<br>
<br>
I've never seen the compiler do wildly unexpected things unless whole<br>
program optimisation is enabled, which I don't imagine D will be able to<br>
support any time real soon?<br>
<br>
...and even then, relying on WPO for the language to generate good code in<br>
certain circumstances is a really really bad idea. This makes the task of<br>
implementing an efficient compiler for the language extremely difficult.<br>
In most cases, making concise expression of the operation you want to<br>
perform possible in the language will generate better results anyway,<br>
without depending on an aggressive optimiser. It will also make the code<br>
more explicit and readable.<br>
<br>
</div></blockquote>
<br>
Manu, please go read the D ABI (<a href="http://dlang.org/abi.html" target="_blank">http://dlang.org/abi.html</a>). Remember, your example of returning two values using Tuple vs 'real' MRV? The D ABI states that those values will be returned via registers. Returning something larger? Then the NVRO kicks in which gives you a zero copy approach. On x86-64 these limits are different, since you have more registers to play with, but the concept is the same. In fact, returning arguments has always been more efficient than passing arguments.<br>

</blockquote></div><div><br></div>Please go read my prior posts. This has absolutely no bearing on what I'm talking about. In fact, it fuels my argument in some cases.<div><br><div>That said, I've read it, and it scares the hell out of me. D states that a small struct may be returned in up to 2 registers (8 bytes/16 bytes), I suspect this is a hack introduced specifically to make ranges efficient?</div>
<div>If it is not simply a struct of 2 register sized things, they get packed into a magic 8-16 byte struct implicitly for return, and this makes my brain explode. If I wanted to perform a bunch of shifts, or's, and and's until it's snugly packed into a 8-16 byte block before returning, I'd do that explicitly... I DON'T want to do that however, and I <b>really</b> don't want the language doing that for me. If I want to return 4 byte values, they should be returned in 4 registers, not packed together into a 32bit word and returned in one. Also, if there are mixed ints, floats, vectors, even other structs, none of it works; what if there is float data? Swapping registers now? That's one of the worst penalties there is.</div>
</div>