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.

1. Support extern(C++) classes so can have a split C++/D implementation of eg: Expression and others.

2. Support representing integers and floats to a greater precision than what the host can natively support. 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.

3. Array ops should be moved out of the front end. The back end can deal with emitting the correct Libcall if required.

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.

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.

6. LDC does not implement toObjFile, toCtype, toDt, toIR, possibly others...

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.

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.

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.

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.

11. The function genCfunc does not generate the arguments of the extern(C) symbol.

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.

13. LDC makes some more arbitrary changes to which the reason for the change has been forgotten. Get on it David!  :o)

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.

15. Deal with all C++ -> D conversion

On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
> 15. Deal with all C++ -> D conversion

15. Deal with all C++ -> D conversion issues (see all DDMD marked pull requests).

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.


Anything else I missed?

Oh, perhaps licensing issues.  I know the C++ sources for the D front end have been assigned to the FSF by Walter,  I think the conversion to D is enough change to warrant reassignment.


1, 2, 3,  get destroying...

Regards
Iain.

On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
> 13. LDC makes some more arbitrary changes to which the reason for the change has been forgotten. Get on it David!  :o)

This applies only to a small part of the changes. The larger share of them will actually need adaption of the upstream frontend sources for a very good reason if we want to have a truly shared codebase.

As for the size of the diff, don't forget that LDC doesn't enjoy the luxury of having IN_LLVM sections in the upstream source – the difference in amount of changes actually isn't that large:

---
$ fgrep -rI IN_GCC dmd/src | wc -l
49

$ fgrep -rI IN_LLVM ldc/dmd2 | wc -l
57
---

David

On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
> 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.

I think we should just add the full list from http://dlang.org/version.html. This would also resolve the issue for LDC.

David

On May 5, 2013 3:30 PM, "David Nadlinger" <see@klickverbot.at> wrote:
>
> On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
>>
>> 13. LDC makes some more arbitrary changes to which the reason for the
change has been forgotten. Get on it David!  :o)
>
>
> This applies only to a small part of the changes. The larger share of
them will actually need adaption of the upstream frontend sources for a very good reason if we want to have a truly shared codebase.
>
> As for the size of the diff, don't forget that LDC doesn't enjoy the
luxury of having IN_LLVM sections in the upstream source – the difference in amount of changes actually isn't that large:
>
> ---
> $ fgrep -rI IN_GCC dmd/src | wc -l
> 49
>
> $ fgrep -rI IN_LLVM ldc/dmd2 | wc -l
> 57
> ---
>
> David

Indeed, but I was thinking of changes that aren't ifdef 'd.  I'm sure I saw a few...

Regards
-- 
Iain Buclaw

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

On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
> 1. Support extern(C++) classes so can have a split C++/D implementation of eg: Expression and others.

I don't know if this will be in the videos, so I'll ask here. I thought extern(C++) only supported interfaces because everything else fell into the "we'd need to pretty much include a C++ compiler into D to support that" camp. Is that not quite true for classes? Did you find some compromise between usefulness and complexity that wasn't obvious before, or did the D compiler transition just motivate adding some additional complexity that previously wasn't deemed acceptable?

On May 5, 2013 5:20 PM, "&lt;luismarques@gmail.com&gt;&quot;@puremagic.com" <&quot;\&quot;Luís&quot;.Marques&quot;> wrote:
>
> On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
>>
>> 1. Support extern(C++) classes so can have a split C++/D implementation
of eg: Expression and others.
>
>
> I don't know if this will be in the videos, so I'll ask here. I thought
extern(C++) only supported interfaces because everything else fell into the "we'd need to pretty much include a C++ compiler into D to support that" camp. Is that not quite true for classes? Did you find some compromise between usefulness and complexity that wasn't obvious before, or did the D compiler transition just motivate adding some additional complexity that previously wasn't deemed acceptable?

It was mentioned, however I do believe there are a few more complicated things than that.  Many would be in a position to educate you on that.

Regards
-- 
Iain Buclaw

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

On 5/5/2013 9:17 AM, "Luís Marques" <luismarques@gmail.com>" wrote:
> On Sunday, 5 May 2013 at 13:33:25 UTC, Iain Buclaw wrote:
>> 1. Support extern(C++) classes so can have a split C++/D implementation of eg:
>> Expression and others.
>
> I don't know if this will be in the videos, so I'll ask here. I thought
> extern(C++) only supported interfaces because everything else fell into the
> "we'd need to pretty much include a C++ compiler into D to support that" camp.
> Is that not quite true for classes? Did you find some compromise between
> usefulness and complexity that wasn't obvious before, or did the D compiler
> transition just motivate adding some additional complexity that previously
> wasn't deemed acceptable?

extern(C++) interfaces are ABI compatible with C++ "com" classes - i.e. single inheritance, no constructors or destructors.

On Sunday, 5 May 2013 at 20:33:15 UTC, Walter Bright wrote:
> extern(C++) interfaces are ABI compatible with C++ "com" classes - i.e. single inheritance, no constructors or destructors.

That I know, thanks, I just understood that point one meant some additional extern(C++) support:

> 1. Support extern(C++) classes so can have a split C++/D implementation of eg: Expression and others.

"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.