I'm expecting lots of positive comments when I get off my flight in 14 hours.

"Daniel Murphy" <yebblies@nospamgmail.com> wrote in message news:km7aqo$2kv4$1@digitalmars.com...
> "Iain Buclaw" <ibuclaw@gdcproject.org> wrote in message news:qtcogcbrhfzjvuoayyjr@forum.dlang.org...
>> Daniel and/or David,
>>
>> We should list down in writing the issues preventing DMD, GDC, and LDC having a shared code base.  From what David has shown me, LDC will need the most work for this, but I'll list down what I can remember.
>>
>
> oooook here we go:
>
> We have three goals:
> A: D frontend ported to D
> B: Identical frontend code shared between all three backends
> C: Fixing the layering violations in the glue layer (in some cases this
> probably blocks B)
>
>> 1. Support extern(C++) classes so can have a split C++/D implementation of eg: Expression and others.
>>
>
> s/others/all ast classes/
> Requred for A only
>
>> 2. Support representing integers and floats to a greater precision than what the host can natively support.
>
> This should be 'Support representing integers and floats to the EXACT precisison that the TARGET supports at runtime'.
>
> The old arguments about how you can't rely on floating point exactness do not hold up when cross compiling - all compilers that differ only in host compiler/machine must produce identical binaries.
>
> This is really a seperate issue.
>
>> In D there's BigInt for integral types, and there's a possibility of using std.numeric for floats.  For me, painless conversion between eg: BigInt <-> GCC's double_int is a requirement, but that is more of an after thought at this point in time.
>>
>
> Because this does not block anything it _can_ wait until the port is complete, we can live with some weirdness in floating point at compile time. I completely agree it should be fixed eventually.
>
>> 3. Array ops should be moved out of the front end. The back end can deal with emitting the correct Libcall if required.
>>
>
> Only blocks C...
>
>> 4. Continue building upon Target to hide target-specific things from the front end.  Off the top of my head I've got two to raise pulls for: __VENDOR__ and retrieving memalignsize for fields.
>>
>
> Only blocks B (and fixing it helps C)
>
>> 5. DMD sends messages to stdout, GDC sends to stderr.  Just a small implementation detail, but worth noting where 'printf'appears, it's almost always rewritten as fprintf(stderr) for GDC.
>>
>
> Similar.
>
>> 6. LDC does not implement toObjFile, toCtype, toDt, toIR, possibly others...
>>
>
> This is another layering violation, and eventually I believe we should migrate to an _actual_ visitor pattern, so ast classes do not need to know anything about the glue layer.  I think we should work around this for now. (With #ifdef, or adding _all_ virtuals to the frontend and stubbing the unused ones)
>
>> 7. BUILTINxxx could be moved into Target, as there is no reason why each back end can't support their own builtins for the purpose of CTFE.
>>
>
> Makes sense.  I guess if Target detects a builtin it gets Port to evaluate it.  Maybe we should rename Port to Host?
>
>> 8. D front end's port.h can't be used by GDC because of dependency  on mars.h, this could perhaps be replaced by std.numeric post conversion.
>>
>
> Didn't we find it doesn't rely on anything substantial?  This can certainly be cleaned up.
>
>> 9. Opaque declarations of back end types defined in front end differ for each compiler implementation.  Eg: elem is a typedef to union tree_node.
>>
>
> Same problem as 6, except opaque types can be safely ignored/used as they are opaque.
>
>> 10. The main function in mars.c is not used by GDC, possibly LDC also. Another implementation detail but also a note to maybe split out errorSuplimental and others from that file.
>>
>
> I'm happy with each compiler having their own 'main' file.  Yes we need to move the common stuff into another file.
>
>> 11. The function genCfunc does not generate the arguments of the extern(C) symbol.
>>
>
> I think this only blocks C.
>
>> 12. LDC adds extra reserved version identifiers that are not allowed to be declared in D code.  This could and probably should be merged into D front end. Don't think it would be wise to let back end's have the ability to add their own.  Also this list needs updating regardless to reflect the documented spec.
>>
>
> Makes sense.
>
>> 13. LDC makes some more arbitrary changes to which the reason for the change has been forgotten. Get on it David!  :o)
>>
>
> I know very little about this but hopefully most of it can go into Target/get merged upstream.
>
>> 14. Reading sources asynchronously, GDC ifdefs this out.  Do we really need this?  I seem to recall that the speed increase is either negliegable or offers no benefit to compilation speed.
>>
>
> I think #ifdefed or dropped are both fine.
>
>> 15. Deal with all C++ -> D conversion
>
> Yeah.
>
>> 16. Testing the C++ -> D front end conversion on Linux.   Daniel you can send me the sources to test that if getting a Linux box is a problem for you.
>
> It's not a problem, just not my primary platform and therefore not my first focus.  At the moment you would need a modified porting tool to compile for anything except win32.  To get here we need to fix the #ifdef-cutting-expressions-and-statements-etc mess.  I'm not sure how bad this is because last time I tried I was going for the backend as well. I'll have a go on my flight until my laptop battery runs out.
>
> There is more, it's just more of the same.
> 

When devising solutions, I want to prefer solutions that do not rely on #ifdef/#endif. I've tried to scrub those out of the dmd front end source code.

"Walter Bright" <newshound2@digitalmars.com> wrote in message news:km7fml$2rka$1@digitalmars.com...
> When devising solutions, I want to prefer solutions that do not rely on #ifdef/#endif. I've tried to scrub those out of the dmd front end source code.

I completely agree.  But - refactoring the glue layer interface to use a proper visitor interface (what I suspect is the best solution) is a rather large change and will be much easier _after_ the conversion.

While ifdefs are a pain in general, the big problem is this pattern.
if (a && b &&
#if SOMETHING
    c && d &&
#else
    e && f &&
#endif
    g && h) {
...

On 6 May 2013 08:19, Daniel Murphy <yebblies@nospamgmail.com> wrote:

> "Walter Bright" <newshound2@digitalmars.com> wrote in message news:km7fml$2rka$1@digitalmars.com...
> > When devising solutions, I want to prefer solutions that do not rely on #ifdef/#endif. I've tried to scrub those out of the dmd front end source code.
>
> I completely agree.  But - refactoring the glue layer interface to use a proper visitor interface (what I suspect is the best solution) is a rather large change and will be much easier _after_ the conversion.
>
> While ifdefs are a pain in general, the big problem is this pattern.
> if (a && b &&
> #if SOMETHING
>     c && d &&
> #else
>     e && f &&
> #endif
>     g && h) {
> ...
>
>
^^ One thing I won't miss about removing all DMDV1 macros from GDC glue. ;)



-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 6 May 2013 05:16, Daniel Murphy <yebblies@nospamgmail.com> wrote:

> "Iain Buclaw" <ibuclaw@gdcproject.org> wrote in message news:qtcogcbrhfzjvuoayyjr@forum.dlang.org...
> > Daniel and/or David,
> >
> > We should list down in writing the issues preventing DMD, GDC, and LDC having a shared code base.  From what David has shown me, LDC will need the most work for this, but I'll list down what I can remember.
> >
>
> oooook here we go:
>
> We have three goals:
> A: D frontend ported to D
> B: Identical frontend code shared between all three backends
> C: Fixing the layering violations in the glue layer (in some cases this
> probably blocks B)
>
> > 1. Support extern(C++) classes so can have a split C++/D implementation
> of
> > eg: Expression and others.
> >
>
> s/others/all ast classes/
> Requred for A only
>
> > 2. Support representing integers and floats to a greater precision than what the host can natively support.
>
> This should be 'Support representing integers and floats to the EXACT precisison that the TARGET supports at runtime'.
>
> The old arguments about how you can't rely on floating point exactness do not hold up when cross compiling - all compilers that differ only in host compiler/machine must produce identical binaries.
>
> This is really a seperate issue.
>
>
Probably yes, but I cannot consider switching without it.



> > In D there's BigInt for integral types, and there's a possibility of
> using
> > std.numeric for floats.  For me, painless conversion between eg: BigInt <-> GCC's double_int is a requirement, but that is more of an after thought at this point in time.
> >
>
> Because this does not block anything it _can_ wait until the port is
> complete, we can live with some weirdness in floating point at compile
> time.
> I completely agree it should be fixed eventually.
>
>
Indeed, and I can deal without BigInt.



> > 3. Array ops should be moved out of the front end. The back end can deal with emitting the correct Libcall if required.
> >
>
> Only blocks C...
>
> > 4. Continue building upon Target to hide target-specific things from the front end.  Off the top of my head I've got two to raise pulls for: __VENDOR__ and retrieving memalignsize for fields.
> >
>
> Only blocks B (and fixing it helps C)
>
> > 5. DMD sends messages to stdout, GDC sends to stderr.  Just a small implementation detail, but worth noting where 'printf'appears, it's
> almost
> > always rewritten as fprintf(stderr) for GDC.
> >
>
> Similar.
>
> > 6. LDC does not implement toObjFile, toCtype, toDt, toIR, possibly others...
> >
>
> This is another layering violation, and eventually I believe we should migrate to an _actual_ visitor pattern, so ast classes do not need to know anything about the glue layer.  I think we should work around this for now. (With #ifdef, or adding _all_ virtuals to the frontend and stubbing the unused ones)
>
> > 7. BUILTINxxx could be moved into Target, as there is no reason why each back end can't support their own builtins for the purpose of CTFE.
> >
>
> Makes sense.  I guess if Target detects a builtin it gets Port to evaluate it.  Maybe we should rename Port to Host?
>
> > 8. D front end's port.h can't be used by GDC because of dependency  on mars.h, this could perhaps be replaced by std.numeric post conversion.
> >
>
> Didn't we find it doesn't rely on anything substantial?  This can certainly be cleaned up.
>
>
Nothing substantial, no.  And cleaned up, it should be.  I just haven't spent more than 5 minutes looking at it.


> 9. Opaque declarations of back end types defined in front end differ for
> > each compiler implementation.  Eg: elem is a typedef to union tree_node.
> >
>
> Same problem as 6, except opaque types can be safely ignored/used as they are opaque.
>
> > 10. The main function in mars.c is not used by GDC, possibly LDC also. Another implementation detail but also a note to maybe split out errorSuplimental and others from that file.
> >
>
> I'm happy with each compiler having their own 'main' file.  Yes we need to move the common stuff into another file.
>
>
Have any suggestions for where to move this? (other than a new file)



> > 11. The function genCfunc does not generate the arguments of the
> extern(C)
> > symbol.
> >
>
> I think this only blocks C.
>
> > 12. LDC adds extra reserved version identifiers that are not allowed to
> be
> > declared in D code.  This could and probably should be merged into D
> front
> > end. Don't think it would be wise to let back end's have the ability to add their own.  Also this list needs updating regardless to reflect the documented spec.
> >
>
> Makes sense.
>
> > 13. LDC makes some more arbitrary changes to which the reason for the change has been forgotten. Get on it David!  :o)
> >
>
> I know very little about this but hopefully most of it can go into Target/get merged upstream.
>
> > 14. Reading sources asynchronously, GDC ifdefs this out.  Do we really need this?  I seem to recall that the speed increase is either
> negliegable
> > or offers no benefit to compilation speed.
> >
>
> I think #ifdefed or dropped are both fine.
>
> > 15. Deal with all C++ -> D conversion
>
> Yeah.
>
> > 16. Testing the C++ -> D front end conversion on Linux.   Daniel you can send me the sources to test that if getting a Linux box is a problem for you.
>
> It's not a problem, just not my primary platform and therefore not my first
> focus.  At the moment you would need a modified porting tool to compile for
> anything except win32.  To get here we need to fix the
> #ifdef-cutting-expressions-and-statements-etc mess.  I'm not sure how bad
> this is because last time I tried I was going for the backend as well.
>  I'll
> have a go on my flight until my laptop battery runs out.
>
> There is more, it's just more of the same.
>
>
>


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

"Daniel Murphy" <yebblies@nospamgmail.com> wrote in message news:km7lir$48g$1@digitalmars.com...
> "Walter Bright" <newshound2@digitalmars.com> wrote in message news:km7fml$2rka$1@digitalmars.com...
>> When devising solutions, I want to prefer solutions that do not rely on #ifdef/#endif. I've tried to scrub those out of the dmd front end source code.
>
> I completely agree.  But - refactoring the glue layer interface to use a proper visitor interface (what I suspect is the best solution) is a rather large change and will be much easier _after_ the conversion.
>
> While ifdefs are a pain in general, the big problem is this pattern.
> if (a && b &&
> #if SOMETHING
>    c && d &&
> #else
>    e && f &&
> #endif
>    g && h) {
> ...

It turns out these are actually not that big a problem in the frontend - around 30 cases, all DMDV2 or 0/1.

The backend is another story...

Do you plan to support a build path that has no circular dependendencies? This would be a very strong nice to have for porting D to new architectures.

So it should be possible to build a subset of D (stage 1) with gcc without relying on a D compiler and than using the stage 1 binary to build a complete D compiler.

There are languages in Debian that rely on themselves to be build and it's a headache to support those languages on all architectures.

Regards, Thomas Koch

On 9 May 2013 10:11, Thomas Koch <thomas@koch.ro> wrote:

> Do you plan to support a build path that has no circular dependendencies? This would be a very strong nice to have for porting D to new architectures.
>
> So it should be possible to build a subset of D (stage 1) with gcc without relying on a D compiler and than using the stage 1 binary to build a complete D compiler.
>
> There are languages in Debian that rely on themselves to be build and it's
> a
> headache to support those languages on all architectures.
>
> Regards, Thomas Koch
>
>
I'll will very likely keep a branch with the C++ implemented front end for these purposes. But ideally we should get porting as soon as possible ahead of this move so that there are already D compilers available for said targets.

Though it would be nice for the D implementation to be kept to a subset that is backwards compatible with 2.062 (or whatever version we decide to make the switch at), that is something I cannot guarantee.


Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Thursday, 9 May 2013 at 09:11:05 UTC, Thomas Koch wrote:
> There are languages in Debian that rely on themselves to be build and it's a
> headache to support those languages on all architectures.

Wouldn't the "normal" workflow for porting to a new platform be to start out with a cross-compiler anyway?

David

On 9 May 2013 12:50, David Nadlinger <see@klickverbot.at> wrote:

> On Thursday, 9 May 2013 at 09:11:05 UTC, Thomas Koch wrote:
>
>> There are languages in Debian that rely on themselves to be build and
>> it's a
>> headache to support those languages on all architectures.
>>
>
> Wouldn't the "normal" workflow for porting to a new platform be to start out with a cross-compiler anyway?
>
> David
>

Currently... only if the target platform does not have a native c++ compiler.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';