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
