I'm expecting lots of positive comments when I get off my flight in 14 hours.
"Daniel Murphy" <yebbl...@nospamgmail.com> wrote in message news:km7aqo$2kv4$1...@digitalmars.com... > "Iain Buclaw" <ibuc...@gdcproject.org> wrote in message > news:qtcogcbrhfzjvuoay...@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. >