On Tuesday, 18 December 2012 at 12:36:31 UTC, Andrej Mitrovic
wrote:
On 12/18/12, foobar <f...@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.
