Multiple return values...

[Manu]

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

> On Sat, 10 Mar 2012 19:27:05 -0600, Manu <turkeyman at gmail.com> wrote:
>
>> On 11 March 2012 00:25, Sean Cavanaugh <WorksOnMyMachine at gmail.com>
>> wrote:
>>
>>  On 3/10/2012 4:37 AM, Manu wrote:
>>>
>>>
>>>> If I pass a structure TO a function by value, I know what happens, a
>>>> copy is written to the stack which the function expects to find there.
>>>>
>>>>
>>> This is only true if the compiler is forced to use the ABI, when inlining
>>> is impossible, or the type being passed is too complex. Structs of pods,
>>> most compilers do magical things to provided you don't actively work
>>> against the code gen (virtual methods, dllexports etc), too many separate
>>> .obj units in C++ etc.
>>>
>>>
>> Talking about the typical case here, obviously not inlined, calling
>> through
>> the ABI, struct may be simple, just 2-3 values, can you show me a case
>> where C++ is able to to anything particularly fancy?
>>
>> I've never seen the compiler do wildly unexpected things unless whole
>> program optimisation is enabled, which I don't imagine D will be able to
>> support any time real soon?
>>
>> ...and even then, relying on WPO for the language to generate good code in
>> certain circumstances is a really really bad idea. This makes the task of
>> implementing an efficient compiler for the language extremely difficult.
>> In most cases, making concise expression of the operation you want to
>> perform possible in the language will generate better results anyway,
>> without depending on an aggressive optimiser. It will also make the code
>> more explicit and readable.
>>
>>
> Manu, please go read the D ABI (http://dlang.org/abi.html). 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.
>

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.

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?
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 *really* 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120311/6f3d3772/attachment.html>