Multiple return values

[Manu]

This is precisely my understanding, and the reason I post the topic.
Tuples are not a reasonable solution.

On 4 January 2012 01:17, Timon Gehr <timon.gehr at gmx.ch> wrote:

> On 01/04/2012 12:09 AM, Manu wrote:
>
>> Does returning a tuple give any ABI guarantees?  How can I be sure
>> multiple return values will return in consecutive
>>
> registers?
>
>  * 1, 2 and 4 byte structs are returned in EAX.
>  * 8 byte structs are returned in EDX,EAX, where EDX gets the most
> significant half.
>  * For other struct sizes, the return value is stored through a hidden
> pointer passed as an argument to the function.
>
>
>
>
>  What if the return types are of different types, a float and an int...
>> can I expect each to return in their own register types respectively?
>>
>
> No.
>
>
>  This needs to be defined and loosely guaranteed (within reason) so
>> people can expect multiple return values to behave as expected on any
>> architecture.
>>
>
> A possibility would be to allow TypeTuple return types.
>
>
>
>> On 4 January 2012 01:02, Sean Kelly <sean at invisibleduck.org
>> <mailto:sean at invisibleduck.org**>> wrote:
>>
>>    It's easy enough with Tuple, though better language support would be
>>    nice.
>>
>>    Sent from my iPhone
>>
>>    On Jan 3, 2012, at 2:40 PM, Manu <turkeyman at gmail.com
>>    <mailto:turkeyman at gmail.com>> wrote:
>>
>>     > Why doesn't D support multiple return values like many other
>>    modern languages?
>>     >
>>     > Clearly the same syntax as Go wouldn't work, but I'm sure a neat
>>    and tidy syntax could be invented?
>>     > I constantly want to be able to return x,y from a function, or
>>    retVal,errorCode and I want the language to make some rough ABI
>>    guarantees, like multiple return values will be returned in
>>    consecutive registers, rather than a single return value register
>>    like C/C++, avoiding the need to pass output addresses through ref
>>    function parameters (slow!).
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120104/940adf6c/attachment.html>