Migrating D front end to D - post Dconf

[Daniel Murphy]

I'm expecting lots of positive comments when I get off my flight in 14 
hours.

"Daniel Murphy" <yebblies at nospamgmail.com> wrote in message 
news:km7aqo$2kv4$1 at digitalmars.com...
> "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.
>