Multiple return values...

[Manu]

On 16 March 2012 18:37, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org>wrote:

> Actually, as has been mentioned, swizzling can be done very nicely inside
> the language.
>

How? The only example I saw in this thread was your from()/to() approach,
which Timon said didn't actually work...?


On 3/16/12 6:29 AM, Manu wrote:
>
>> Requiring inlining to make it efficient is not enough. The proposed MRV
>
> ABI would solve this not only for inlines, but for all multi-assignment
>> type constructs, including distant function calls.
>>
>
> If changing the ABI is on the table, I wonder whether we can improve it
> for all structures, not only for multiple return types. Overall I agree
> that defining a specialized ABI for leaving multiple values on the stack
> would be marginally more efficient, but (a) I don't know by how much, and
> (b) I don't know whether it's worth changing the language.


It might be that this technology is simpler to implement as applied to all
structs (which would include tuples). That way it may additionally address
the current problem with slices and delegates. If it applies too all
structs, there probably needs to be a cut-off heuristic though, since
explicit structs would tend to be a lot bigger than a few MRV values, and
named return values is probably better in that context. Implementation
details would reveal themselves when trying to write the code I think, ie,
where to draw the line (structure size/recursion, etc).

(a) 'Marginally' spread across the entire program eventually adds up to a
lot, especially if it finds its self in hot loops. C/C++ compilers have
extremely aggressive low level optimisers. There is obviously someone who
agrees that that effort and reduction in compiler performance is
worthwhile, or they wouldn't do it...
In terms of benchmarks (the quantity of value you are looking for), it
probably won't make so much difference to existing code, because people
avoid returning structs by value like the plague It's just something you
simply don't do. But if it were a real feature that were reliable, I can
see it quickly replace returning through references passed in the parameter
list (a horrible concept conceptually, effectively a hack), and it would
start to show its value as more and more code were written that way. We
free up an argument register in the call where we would have previously
passed the ref/pointer, and the return doesn't produce a memory write+read
(an LHS hazard). This is a good few opcodes, memory access, and elimination
of a major architectural hazard. Repeat this throughout your code base...
the only reason it's not in C, is because the ABI far too engraved and can
never be changed.

(b) Is it a change to the language? Just a change to the ABI with respect
to returning a tuple.
The change to the language is the unpack syntax, which should be argued on
a completely separate basis.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120316/724ca640/attachment.html>