On Monday, 23 November 2015 at 21:05:29 UTC, Walter Bright wrote:
> The code looks quite good. I've been trying to adjust things, however, so there are no pushes and pops in the code, trying to preallocate everything needed in the function prolog.

Wouldn't you still need to restore the stack before leaving the function (tail call in this case)?

For a single register, push/pop is probably still cheaper than setting up RBP and having the extra mov/sub.

> dmd rewrites try-catch-finally into try-{try-catch}-finally, which makes it easier to generate code, because fewer special cases and fewer bugs. I've become a big fan of that technique

Except that we actually need to flatten all the nesting into a single landing pad anyway. How would you do this in DMD? I didn't realize you could even have multiple EH table entries attached to a single code location.

 — David

On 11/23/2015 4:36 PM, David Nadlinger wrote:
> On Monday, 23 November 2015 at 21:05:29 UTC, Walter Bright wrote:
>> The code looks quite good. I've been trying to adjust things, however, so
>> there are no pushes and pops in the code, trying to preallocate everything
>> needed in the function prolog.
>
> Wouldn't you still need to restore the stack before leaving the function (tail
> call in this case)?

Yes.


>> dmd rewrites try-catch-finally into try-{try-catch}-finally, which makes it
>> easier to generate code, because fewer special cases and fewer bugs. I've
>> become a big fan of that technique
>
> Except that we actually need to flatten all the nesting into a single landing
> pad anyway.

I don't know why that would be true. gdc generates multiple landing pads.


> How would you do this in DMD? I didn't realize you could even have
> multiple EH table entries attached to a single code location.

You can't. The most deeply nested one gets the table entry.

On Monday, 23 November 2015 at 21:38:39 UTC, Walter Bright wrote:
> On 11/23/2015 1:32 PM, deadalnix wrote:
>> On Monday, 23 November 2015 at 21:05:29 UTC, Walter Bright wrote:
>>> dmd rewrites try-catch-finally into try-{try-catch}-finally, which makes it
>>> easier to generate code, because fewer special cases and fewer bugs. I've
>>> become a big fan of that technique :-)
>>
>> Wouldn't that makes unwinding slower because one need to go through several
>> landing pads ?
>>
>
> Yes. But if you're choked by unwinding speed, you're doing it wrong.

I don't think this is a good reason for making it twice as slow :)

On 2015-11-23 19:18, Walter Bright wrote:

> My eevil plan is to get D exceptions working completely before trying to
> support std::exception.

Is the idea to replace the existing exception handling mechanism for D code that don't interact with C++ as well?

-- 
/Jacob Carlborg

On Tuesday, 24 November 2015 at 07:52:13 UTC, Jacob Carlborg wrote:
> On 2015-11-23 19:18, Walter Bright wrote:
>
>> My eevil plan is to get D exceptions working completely before trying to
>> support std::exception.
>
> Is the idea to replace the existing exception handling mechanism for D code that don't interact with C++ as well?

Walter is moving DMD to use libunwind.