Multiple return values

Manu turkeyman at gmail.com
Wed Jan 4 15:03:16 PST 2012


On 4 January 2012 16:23, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org>wrote:

> On 1/4/12 2:36 AM, Manu wrote:
>
>> Regardless, I'd like to put a strong +1 towards proper multiple return
>> values. The point is NOT just to have the syntactical feature (ie.
>> struct return value semantics via tuples). The point is a language
>> guarantee that the architecture will do its best job to return each
>> value in consecutive registers OF ITS OWN TYPE, avoiding
>> allocation&writing to the stack. This is a common problem in C where the
>> only solution is to make functions inline or pay the cost of hitting the
>> stack (LHS hazard, very expensive on many RISC architectures).
>> It would lead to many optimisations in lots of code in my experience.
>>
>
> Why make those optimizations only for multiple return values and not for
> every single returned structure?


I think multiple return values and returning a struct (tuple) are
fundamentally different things...
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.

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.
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...
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'...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120105/824703b9/attachment.html>


More information about the Digitalmars-d mailing list