D Frontend and shared code base (moving away from calling it DMD front-end).

[Iain Buclaw]

On Tuesday, 18 December 2012 at 12:36:31 UTC, Andrej Mitrovic 
wrote:
> On 12/18/12, foobar <foo at bar.com> wrote:
>> Besides, the other compilers merge in the same front-end
>> code so they'll gain the same feature anyway. There's no gain 
>> in
>> separating it out to rdmd.
>
> Adding more front-end features adds more work for maintainers of
> compilers which are based on the DMD front-end, and not all 
> compilers
> are based on the DMD front-end.
>

9 times out of 10 any new features don't harm compilers for other 
backends. The only ones you need to look out for are features 
that pass new information to the backend to handle (eg: nullable 
types and vectors were the last two off the top of my head).


Also, personally I refer to it as the D Front-end (or DFE for 
short sometimes in IRC), as for the most part, it has long since 
been specific only for DMD.

However, the situation could be better though. Despite me 
regarding the frontend as shared code, it is far from that. As 
GDC and LDC make quite a lot of changes to make DFE work with 
their respective backends and for portability to non-x86 
architectures. See this diff between LDC, DMD and GDC as an 
example of just how bad the current situation is.

http://img21.imageshack.us/img21/1396/meldview1.png


I have spent quite a huge amount of time trying to thin down on 
these differences, as it does ease the merge process when a new 
update to DFE gets rolled out.  The following is an example where 
I moved the building of these calls to the GDC glue code, at the 
expense of GDC's codebase growing in size.

http://img43.imageshack.us/img43/4922/meldview3.png


By and large though, LDC and GDC actually share a lot of 
backend-specific changes. Here's an example which returns the 
target align size of types.

http://img191.imageshack.us/img191/6156/meldview2.png


For these cases when portability mattered, I'd hope that these 
sorts of changes wouldn't need to be conditional, and I'd rather 
the DFE to be a common repository used for all the compilers 
using it.  Any discrepancies between the compilers replaced with 
a hook that is unconditional, and left to the compiler 
maintainer's job to implement in the correct way for them.


Hopefully, I'd like to get the core developers of D Front-end to 
work with the people maintaining other such compilers (GDC, LDC, 
and any others that might come into existance) so that there can 
genuinely be a shared, portable source base for the D Front-end 
code, to be used by all maintainers, without conditionals based 
on which compiler it's used in, and with that shared source base 
only using an absolute minimum of headers from DMD backend.

This could be done with a new interface, for example struct 
target. Meaning the example in the screenshot above would be 
reduced to the following shared code.

unsigned TypeBasic::alignsize()
{
     return target.alignsize(this);
}


I'll let you all brood over that though, and would welcome any 
feedback to get some sort of plan rolling (even if it's just a 
DIP).


Thanks,
Iain.