On 21 Jul 2015 00:00, "Martin Nowak via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Monday, 20 July 2015 at 09:10:13 UTC, Iain Buclaw wrote:
>>
>> I just have one request.  We need to designate a supported version of
the compiler (2.069?) as the base to which we convert and maintain compatibility for, and do not introduce any new features after that point.
>
>
> I don't fully understand what you're asking for.
> Can you tell us what problem you're trying to address instead of which
solution to apply.

1. If you want ddmd to be compilable by both gdc and ldc then you can't introduce any new features to the ddmd codebase post conversion.

The work you've left me is an added burden that was ultimately welcome, but unasked for. So expect things to halt on my side for some time as I'm going through a partial rewrite.

2. Simplifies bootstrap for porting to self-hosted D.

Though the gdc compiler is available in Debian on all supported platforms - some 16 in total - the library is still only being built on x86 and ARM, because of lack of testing or build failures.

Having the last C++ frontend being able to build the latest D frontend allows the transition for these targets that need their runtime library ported and tested easier.  The reality still is that C++ has the upper hand for being more portable, but there should be no reason why we can't run everywhere C++ runs granted there is an OS.

3. Force stability language through codebase.  Maybe ddmd will be a bad example as it's pretty much written in the style of a Poor-mans-C++-in-D. But not breaking language compatibility between 2.068 and LATEST should help reduce regressions between versions.  Most people I've talked to agree.

Iain.

On 7/20/2015 8:47 PM, Iain Buclaw via Digitalmars-d wrote:
> 3. Force stability language through codebase.  Maybe ddmd will be a bad example
> as it's pretty much written in the style of a Poor-mans-C++-in-D.  But not
> breaking language compatibility between 2.068 and LATEST should help reduce
> regressions between versions.  Most people I've talked to agree.

I agree it makes sense to stick with 2.068 to compile ddmd until gdc and ldc can switch to ddmd.

On Tuesday, 21 July 2015 at 03:19:16 UTC, Iain Buclaw wrote:
> On 21 Jul 2015 00:45, "Jonathan M Davis via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>>
>> On Monday, 20 July 2015 at 22:26:53 UTC, rsw0x wrote:
>>>
>>> because versions are released with GDC and LDC lagging 2-3 versions
> behind, when DMD is unusable for production quality codegen.
>>>
>>> 2.068 is almost out and GDC and LDC both only support 2.066. Until D
> decides to adopt either GDC or LDC as a real backend, this will never be fixed.
>>
>>
>> Unifying the frontend will go a long way towards fixing this problem, and
> Daniel is working on that right now. He's aiming to make it so that the frontend is identical across all three compilers so that the ldc and gdc developers don't have to fork it like they do now.
>>
>
> Hardly. All he can take credit for is removing the virtual method interface and replacing them with visitors (which can be described as no small job, but benefitted more towards ddmd).
>
> Everything else has been a slow, tedious three year job from yours truly to remove all x86-isms and platform-specific handling out of the frontend.

Sorry. I was not trying to take credit away from you or anyone else. I just know that Daniel considers getting the frontend to the point that it's identical across all three compilers to be the top priority, and as of dconf at least, that's what he was focusing on. I mentioned him, because I knew he was working on it.

I'm certainly grateful for the stuff that you've done, though admittedly, I don't keep up with what's happening with any of the compilers very well, so you're bound to have done a lot more than I'm aware of.

> There are a more than a few last leg things to be done, some are in PRs raised by me, but or not being looked at, or understood properly.
>
> Example, I moved underscore prefixing hacks for OSX out of the frontend (every single one broke GDC ABI in one way or another) and into Target. Then Walter slams it for being pointless refactoring.
>
> Target is a concept raised at DConf 2013 where I bounced the idea that all uses of global.params.isXXX should be removed from the frontend as all are there to only address a perk of DMD when targeting that platform.  The end goal then becomes to make it so that instead of asking 'Is my target OSX?', what the frontend should be asking is 'Does the target add prefixes to symbols?'
>
> I shouldn't have to explain why the latter benefits all.

Yeah. Walter seems surprisingly resistant to making changes that make the frontend identical across the three compilers. David and Daniel were arguing with him over something related to that at dconf and were having a hard time getting him to even consider it (though in that case, it was because he was afraid it would slow the compiler down rather being an issue with refactoring). In your case, you might have had bad timing (depending on when your work was rejected), since just prior to dconf Walter was getting annoyed with the higher than normal number of regressions and decided that excessive refactoring was to blame (which it may or may not have been), which would tend to make him a lot more resistant to accepting refactoring even with a good reason. Hopefully, he can be convinced of it at some point.

- Jonathan M Davis

Maybe it's really better to jump ddmd to 2.1 version and stay 2.06+ for compatibility purpose? The something similar was with D1 time, when for a long times it's get new updates.

On Tuesday, 21 July 2015 at 03:47:11 UTC, Iain Buclaw wrote:
> 1. If you want ddmd to be compilable by both gdc and ldc then you can't introduce any new features to the ddmd codebase post conversion.

Sticking to 2.068 will help for some time but is not a long-term solution. Particularly when considering some of the bigger D issues left to resolve, we'll likely have to deal with some incompatibilities/deprecations.
Also consider that we might use the stable phobos parts.

I made a Trello card, let's discuss the details when we're actually working on this. https://trello.com/c/4NtxWDtK/30-compatibility-implications-for-self-hosting-d-compiler

On Monday, 20 July 2015 at 23:01:26 UTC, Walter Bright wrote:
> That's right. Trying to fix bugs while translating doesn't work very well. The idea is to get a 2.068 workalike to use as a baseline. Regressions can, of course, still be pushed to the 2.068 line.
>
> That said, one can still post PR's for fixes. No reason to stop doing that.

Please target the stable branch with regression fixes.
We might create a long term 2.068 branch before using stable for 2.069.

On Monday, 20 July 2015 at 23:20:58 UTC, Walter Bright wrote:
> First we have to make sure we know why it is slower.

I got this number from Daniel, he didn't found a reason.
Chances are it's uniformly slower because of dmd's backend, but of course profiling might help.

On Monday, 20 July 2015 at 23:11:57 UTC, Walter Bright wrote:
>> They are definitely very high priority, but I'd also like us to address all the
>> import (313+314) and protection issues (DIP22) this year.
>
> What is high priority is certainly debatable, but what is most clear to me is that transitioning to D source code has finally bubbled to the top of the stack.

It makes sense to spent quite some time on the D transition b/c it's feasible, thanks to Daniel's work, and might have a good impact on compiler contributions.
Still we should have that debate and prioritize the bigger remaining D issues, e.g. for the 2015H2 vision.

On 21 July 2015 at 08:19, Martin Nowak via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Tuesday, 21 July 2015 at 03:47:11 UTC, Iain Buclaw wrote:
>>
>> 1. If you want ddmd to be compilable by both gdc and ldc then you can't introduce any new features to the ddmd codebase post conversion.
>
>
> Sticking to 2.068 will help for some time but is not a long-term solution.
> Particularly when considering some of the bigger D issues left to resolve,
> we'll likely have to deal with some incompatibilities/deprecations.
> Also consider that we might use the stable phobos parts.
>
> I made a Trello card, let's discuss the details when we're actually working
> on this.
> https://trello.com/c/4NtxWDtK/30-compatibility-implications-for-self-hosting-d-compiler
>

Phobos may not be a problem depending on what ends up being decided - there have been both arguments for and against Phobos being used in ddmd.

I certainly don't want to have bugs get in the way, so it is in my interest to have some sort of backport window open for 2.068 as ddmd transforms out of it's current design.

Iain

Am Tue, 21 Jul 2015 05:10:45 +0200
schrieb Iain Buclaw via Digitalmars-d <digitalmars-d@puremagic.com>:

> On 21 Jul 2015 00:45, "Jonathan M Davis via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
> >
> > On Monday, 20 July 2015 at 22:26:53 UTC, rsw0x wrote:
> >>
> >> because versions are released with GDC and LDC lagging 2-3 versions
> behind, when DMD is unusable for production quality codegen.
> >>
> >> 2.068 is almost out and GDC and LDC both only support 2.066. Until D
> decides to adopt either GDC or LDC as a real backend, this will never be fixed.
> >
> >
> > Unifying the frontend will go a long way towards fixing this problem, and
> Daniel is working on that right now. He's aiming to make it so that the frontend is identical across all three compilers so that the ldc and gdc developers don't have to fork it like they do now.
> >
> 
> Hardly. All he can take credit for is removing the virtual method interface and replacing them with visitors (which can be described as no small job, but benefitted more towards ddmd).
> 
> Everything else has been a slow, tedious three year job from yours truly to remove all x86-isms and platform-specific handling out of the frontend.
> 
> There are a more than a few last leg things to be done, some are in PRs raised by me, but or not being looked at, or understood properly.
> 
> Example, I moved underscore prefixing hacks for OSX out of the frontend (every single one broke GDC ABI in one way or another) and into Target. Then Walter slams it for being pointless refactoring.
> 
> Target is a concept raised at DConf 2013 where I bounced the idea that all uses of global.params.isXXX should be removed from the frontend as all are there to only address a perk of DMD when targeting that platform.  The end goal then becomes to make it so that instead of asking 'Is my target OSX?', what the frontend should be asking is 'Does the target add prefixes to symbols?'
> 
> I shouldn't have to explain why the latter benefits all.
> 
> Iain
> 

That also summarizes my biggest doubts regarding frontend unification: We have quite some DMD-backend-specific stuff in the shared frontend (profiler, ...) and nobody complained about that. OTOH adding GDC specific stuff to the frontend (e.g. GDC inline ASM pull #4472) is always met with scepticism.

Such gdc-specific frontend changes are fortunately rare. But with our own frontend fork we can simply commit them. With a unified frontend we'll have to spent hours convincing dmd devs that we need these changes for GDC.