On 6 May 2013 05:16, Daniel Murphy <yebbl...@nospamgmail.com> wrote: > "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. > > 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';