Multiple return values...

[Manu]

On 11 March 2012 18:50, Robert Jacques <sandford at jhu.edu> wrote:

> On Sun, 11 Mar 2012 05:57:05 -0500, Manu <turkeyman at gmail.com> wrote:
>
>  On 11 March 2012 04:35, Sean Cavanaugh <WorksOnMyMachine at gmail.com>
>> wrote:
>>
>>  On 3/10/2012 8:08 PM, Mantis wrote:
>>>
>>>  Tuple!(float, float) callee() {
>>>> do something to achieve result in st0,st1
>>>> fst st0, st1 into stack
>>>> load stack values into EAX, EDX
>>>> ret
>>>> }
>>>>
>>>> void caller() {
>>>> call callee()
>>>> push EAX, EDX into a stack
>>>> fld stack values into st0, st1
>>>> do something with st0, st1
>>>> }
>>>>
>>>> As opposed to:
>>>>
>>>> Tuple!(float, float) callee() {
>>>> do something to achieve result in st0,st1
>>>> ret
>>>> }
>>>>
>>>> void caller() {
>>>> call callee()
>>>> do something with st0, st1
>>>> }
>>>>
>>>> Is there something I miss here?
>>>>
>>>>
>>> Yes, the fact the FPU stack is deprecated :)
>>>
>>>
>> Don't dismiss the point, the same still stands true with XMM regs.
>>
>>
> And Walter has talked about using the XMM registers to return floating
> point data for exactly this reason. But those optimization apply to all
> structs and all data types. There's nothing special about MRV. It has to
> return a set of data in a structured manner; this is identical to the case
> of returning a struct.
>

Well you can't build these sorts of tightly packed structs in XMM
registers... and even for the GPR's, it's very inefficient to do so. I
haven't done tests, but I suspect this feature is probably a
de-optimisation in all cases other than an int-pair struct (ranges,
delegates? I suspect that's why this was invented). Structure
packing/unpacking code will likely be slower than a store/load.

We just need proper multiple return values, then this can go away. And the
earlier any ABI breaking changes are implemented, the better, while there
are still few(/none?) closed source, binary distributed D libraries.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120311/39977a8e/attachment.html>