Migrating D front end to D - post Dconf

[Iain Buclaw]

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

> "Iain Buclaw" <ibuclaw at gdcproject.org> wrote in message
> news:qtcogcbrhfzjvuoayyjr at 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';
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130506/c03eb961/attachment-0001.html>