Migrating dmd to D?

[Iain Buclaw]

On Mar 5, 2013 6:56 AM, "Daniel Murphy" <yebblies at nospamgmail.com> wrote:
>
> "David Nadlinger" <see at klickverbot.at> wrote in message
> news:tbfgbhevqojgnawnxgns at forum.dlang.org...
> >
> > Second, rewriting all of *LDC's* code in D would be a huge task, as the
> > use of C++ templates is pervasive through the LLVM C++ API (even if they
> > are used pretty judiciously), and the LLVM C API is a lot less powerful
in
> > some aspects. Thus, care should be taken that the D frontend can
actually
> > be used with some of the virtual method implementations still in C++
(e.g.
> > toElem/toElemDtor and similar LDC-specific ones).
> >
> > Your (Andrei's) initial post sounded like this would be the case. But
if I
> > interpreted some of the posts correctly, Daniel Murphy has an automatic
> > translator in the works for porting over the whole compiler (except for
> > the backend) at once, which might be a problem for LDC.
> >
> > David
>
> I think we can solve this, but it's a lot of work.
>
> 1. Refactor the glue layer to use a proper visitor pattern
> 2. Implement extern(C++) classes (where
> https://github.com/D-Programming-Language/dmd/pull/644 was supposed to be
> headed)
>
> This should allow us to have the dmd glue layer written in D, with the
> ldc/gdc glue layers written in c++.
>
> It would require all three glue layers to be refactored together, but I
> don't see a way to avoid this.  Hopefully we can get rid of most of the
> gdc/ldc specific frontend patches along the way.
>
> What do you and Iain think about this approach?
>
>

I think C++ classes would be more ill to implement than what I see
initially in that link.

Mangling is another problem as well.  I've seen differing C++ compilers
have subtle differences.  I'll try to find one discrepancy between D and
g++.

Regards
-- 
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/20130305/76a2ab55/attachment-0001.html>