Migrating D front end to D - post Dconf

[Daniel Murphy]

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

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