Migrating dmd to D?

[Iain Buclaw]

On 11 March 2013 16:01, Daniel Murphy <yebblies at nospamgmail.com> wrote:

> "dennis luehring" <dl.soluz at gmx.net> wrote in message
> news:khku3t$15ja$1 at digitalmars.com...
> > Am 11.03.2013 16:23, schrieb Daniel Murphy:
> >> "dennis luehring" <dl.soluz at gmx.net> wrote in message
> >> news:khkqug$v57$1 at digitalmars.com...
> >>> Am 11.03.2013 15:20, schrieb Daniel Murphy:
> >>>> "Daniel Murphy" <yebblies at nospamgmail.com> wrote in message
> >>>> news:khfoa6$fm7$1 at digitalmars.com...
> >>>>> "Daniel Murphy" <yebblies at nospamgmail.com> wrote in message
> >>>>> news:kgumek$2tp4$1 at digitalmars.com...
> >>>>>> "Zach the Mystic" <reachBUTMINUSTHISzach at gOOGLYmail.com> wrote in
> >>>>>> message
> >>>>>> news:pabfuaorrjbljxzrglbv at forum.dlang.org...
> >>>>>>>>
> >>>>>>>> Something like this https://github.com/yebblies/magicport2 ?
> >>>>>>>
> >>>>>>> Yes! I need to look it over more thoroughly, but I couldn't ask for
> >>>>>>> a
> >>>>>>> better beginning. Can I trust that you'll be a willing part of
> >>>>>>> future
> >>>>>>> discussions on this matter, even if only to play Devil's Advocate?
> >>>>>>
> >>>>>> More like a full-blown attempt than a beginning.  I started this a
> >>>>>> long
> >>>>>> time ago.
> >>>>>>
> >>>>>> There are three parts to it:
> >>>>>> - c++ parser/d printer, with lots of cheating and special cases
> >>>>>> - patches to the c++ source
> >>>>>> - patched version of dmd to build the result (no error on variable
> >>>>>> shadowing etc)
> >>>>>>
> >>>>>> It produces a 70000 line d file which appears to get through 3/7ths
> >>>>>> of
> >>>>>> semantic1.  Root needs to be ported, and a cleaner interface to the
> >>>>>> backend is needed to compile the glue layer.
> >>>>>>
> >>>>>
> >>>>> Update: With the bulk of root converting or ported, and the glue
> layer
> >>>>> stubbed out, I can build dmd from the converted source then lex and
> >>>>> parse
> >>>>> the source (+druntime headers) again.
> >>>>>
> >>>>> The highlight was the dynamically resized struct in root/stringtable.
> >>>>> Something went horribly wrong there.
> >>>>
> >>>> Update: I can now generate the source, then build a frontend from
> that,
> >>>> then
> >>>> process the frontend's source again with the built compiler.  It also
> >>>> works
> >>>> on the conversion tool, and pulls in a sizeable chunk of druntime and
> >>>> phobos.
> >>>
> >>> do i get it right - you've converted the dmd C++ code with it?
> >>>
> >>
> >> Umm...
> >>
> >> C++ compiler source -> my tool -> D source
> >> D source -> normal dmd -> self-host dmd
> >> D source -> self-host dmd -> no problems, but only the frontend so no
> >> code
> >> generation
> >> tool source -> self-host dmd -> same thing
> >
> > but interesting enough to get its own root newsgroup post i think - or
> > it the "quality"(converted source etc. whatever) too bad
> >
> >
>
> I'm planning to when it can do the entire test suite, and all of phobos and
> druntime.
>
> The code generated is very close to what you would get running it though a
> (bad) formatter, with comments removed.  I will eventually preserve the
> comments and improve the formatting.
>
> Performance wise the code is pretty nasty because I'm allocating all
> OutBuffers on the heap and inserting tracing code.  This will need to be
> fixed eventually but is fine for checking correctness.
>
> Here's an example conversion: (from PrettyFuncInitExp)
>
> Almost all of the differences are from the primitive pretty-printer.
>
> --------------------------------------------------------
> C++ version
> --------------------------------------------------------
>
> Expression *PrettyFuncInitExp::resolveLoc(Loc loc, Scope *sc)
> {
>     FuncDeclaration *fd;
>     if (sc->callsc && sc->callsc->func)
>         fd = sc->callsc->func;
>     else
>         fd = sc->func;
>
>     const char *s;
>     if (fd)
>     {
>         const char *funcStr = fd->Dsymbol::toPrettyChars();
>         HdrGenState hgs;
>         OutBuffer buf;
>         functionToCBuffer2((TypeFunction *)fd->type, &buf, &hgs, 0,
> funcStr);
>         buf.writebyte(0);
>         s = (const char *)buf.extractData();
>     }
>     else
>     {
>         s = "";
>     }
>
>     Expression *e = new StringExp(loc, (char *)s);
>     e = e->semantic(sc);
>     e = e->castTo(sc, type);
>     return e;
> }
>
>
> --------------------------------------------------------
> D version
> --------------------------------------------------------
>
>     Expression resolveLoc(Loc loc, Scope sc)
>     {
>     tracein("resolveLoc");
>     scope(success) traceout("resolveLoc");
>     scope(failure) traceerr("resolveLoc");
>     {
>         FuncDeclaration fd;
>         if ((sc.callsc && sc.callsc.func))
>         (fd = sc.callsc.func);
>          else (fd = sc.func);
>         const(char)* s;
>         if (fd)
>         {
>             const(char)* funcStr = fd.Dsymbol.toPrettyChars();
>             HdrGenState hgs;
>             OutBuffer buf = new OutBuffer();
>             functionToCBuffer2((cast(TypeFunction)fd.type), buf, (&hgs), 0,
> funcStr);
>             buf.writebyte(0);
>             (s = (cast(const(char)*)buf.extractData()));
>         }
>          else {
>             (s = "");
>         }
>         Expression e = (new StringExp(loc, (cast(char*)s)));
>         (e = e.semantic(sc));
>         (e = e.castTo(sc, type));
>         return e;
>     }
>     }
>
>
>
(The D conversion seems to think it's lisp).

-- 
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/20130311/146a23e7/attachment-0001.html>