<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 6 May 2013 05:16, Daniel Murphy <span dir="ltr"><<a href="mailto:yebblies@nospamgmail.com" target="_blank">yebblies@nospamgmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">"Iain Buclaw" <<a href="mailto:ibuclaw@gdcproject.org">ibuclaw@gdcproject.org</a>> wrote in message<br>
news:qtcogcbrhfzjvuoayyjr@forum.dlang.org...<br>
<div class="im">> Daniel and/or David,<br>
><br>
> We should list down in writing the issues preventing DMD, GDC, and LDC<br>
> having a shared code base. From what David has shown me, LDC will need<br>
> the most work for this, but I'll list down what I can remember.<br>
><br>
<br>
</div>oooook here we go:<br>
<br>
We have three goals:<br>
A: D frontend ported to D<br>
B: Identical frontend code shared between all three backends<br>
C: Fixing the layering violations in the glue layer (in some cases this<br>
probably blocks B)<br>
<div class="im"><br>
> 1. Support extern(C++) classes so can have a split C++/D implementation of<br>
> eg: Expression and others.<br>
><br>
<br>
</div>s/others/all ast classes/<br>
Requred for A only<br>
<div class="im"><br>
> 2. Support representing integers and floats to a greater precision than<br>
> what the host can natively support.<br>
<br>
</div>This should be 'Support representing integers and floats to the EXACT<br>
precisison that the TARGET supports at runtime'.<br>
<br>
The old arguments about how you can't rely on floating point exactness do<br>
not hold up when cross compiling - all compilers that differ only in host<br>
compiler/machine must produce identical binaries.<br>
<br>
This is really a seperate issue.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Probably yes, but I cannot consider switching without it.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
> In D there's BigInt for integral types, and there's a possibility of using<br>
> std.numeric for floats. For me, painless conversion between eg: BigInt<br>
> <-> GCC's double_int is a requirement, but that is more of an after<br>
> thought at this point in time.<br>
><br>
<br>
</div>Because this does not block anything it _can_ wait until the port is<br>
complete, we can live with some weirdness in floating point at compile time.<br>
I completely agree it should be fixed eventually.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Indeed, and I can deal without BigInt.<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
> 3. Array ops should be moved out of the front end. The back end can deal<br>
> with emitting the correct Libcall if required.<br>
><br>
<br>
</div>Only blocks C...<br>
<div class="im"><br>
> 4. Continue building upon Target to hide target-specific things from the<br>
> front end. Off the top of my head I've got two to raise pulls for:<br>
> __VENDOR__ and retrieving memalignsize for fields.<br>
><br>
<br>
</div>Only blocks B (and fixing it helps C)<br>
<div class="im"><br>
> 5. DMD sends messages to stdout, GDC sends to stderr. Just a small<br>
> implementation detail, but worth noting where 'printf'appears, it's almost<br>
> always rewritten as fprintf(stderr) for GDC.<br>
><br>
<br>
</div>Similar.<br>
<div class="im"><br>
> 6. LDC does not implement toObjFile, toCtype, toDt, toIR, possibly<br>
> others...<br>
><br>
<br>
</div>This is another layering violation, and eventually I believe we should<br>
migrate to an _actual_ visitor pattern, so ast classes do not need to know<br>
anything about the glue layer. I think we should work around this for now.<br>
(With #ifdef, or adding _all_ virtuals to the frontend and stubbing the<br>
unused ones)<br>
<div class="im"><br>
> 7. BUILTINxxx could be moved into Target, as there is no reason why each<br>
> back end can't support their own builtins for the purpose of CTFE.<br>
><br>
<br>
</div>Makes sense. I guess if Target detects a builtin it gets Port to evaluate<br>
it. Maybe we should rename Port to Host?<br>
<div class="im"><br>
> 8. D front end's port.h can't be used by GDC because of dependency on<br>
> mars.h, this could perhaps be replaced by std.numeric post conversion.<br>
><br>
<br>
</div>Didn't we find it doesn't rely on anything substantial? This can certainly<br>
be cleaned up.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Nothing substantial, no. And cleaned up, it should be. I just haven't spent more than 5 minutes looking at it.<br><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
> 9. Opaque declarations of back end types defined in front end differ for<br>
> each compiler implementation. Eg: elem is a typedef to union tree_node.<br>
><br>
<br>
</div>Same problem as 6, except opaque types can be safely ignored/used as they<br>
are opaque.<br>
<div class="im"><br>
> 10. The main function in mars.c is not used by GDC, possibly LDC also.<br>
> Another implementation detail but also a note to maybe split out<br>
> errorSuplimental and others from that file.<br>
><br>
<br>
</div>I'm happy with each compiler having their own 'main' file. Yes we need to<br>
move the common stuff into another file.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Have any suggestions for where to move this? (other than a new file)<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">
> 11. The function genCfunc does not generate the arguments of the extern(C)<br>
> symbol.<br>
><br>
<br>
</div>I think this only blocks C.<br>
<div class="im"><br>
> 12. LDC adds extra reserved version identifiers that are not allowed to be<br>
> declared in D code. This could and probably should be merged into D front<br>
> end. Don't think it would be wise to let back end's have the ability to<br>
> add their own. Also this list needs updating regardless to reflect the<br>
> documented spec.<br>
><br>
<br>
</div>Makes sense.<br>
<div class="im"><br>
> 13. LDC makes some more arbitrary changes to which the reason for the<br>
> change has been forgotten. Get on it David! :o)<br>
><br>
<br>
</div>I know very little about this but hopefully most of it can go into<br>
Target/get merged upstream.<br>
<div class="im"><br>
> 14. Reading sources asynchronously, GDC ifdefs this out. Do we really<br>
> need this? I seem to recall that the speed increase is either negliegable<br>
> or offers no benefit to compilation speed.<br>
><br>
<br>
</div>I think #ifdefed or dropped are both fine.<br>
<div class="im"><br>
> 15. Deal with all C++ -> D conversion<br>
<br>
</div>Yeah.<br>
<div class="im"><br>
> 16. Testing the C++ -> D front end conversion on Linux. Daniel you can<br>
> send me the sources to test that if getting a Linux box is a problem for<br>
> you.<br>
<br>
</div>It's not a problem, just not my primary platform and therefore not my first<br>
focus. At the moment you would need a modified porting tool to compile for<br>
anything except win32. To get here we need to fix the<br>
#ifdef-cutting-expressions-and-statements-etc mess. I'm not sure how bad<br>
this is because last time I tried I was going for the backend as well. I'll<br>
have a go on my flight until my laptop battery runs out.<br>
<br>
There is more, it's just more of the same.<br>
<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>Iain Buclaw<br><br>*(p < e ? p++ : p) = (c & 0x0f) + '0';
</div></div>