Bill Baxter wrote:
Of course that back end was also designed for C/C++ originally, right?
Pretty much all of them are.
But anyway, I agree with bearophile, that requiring too many special
features out of a back end will make it hard for any alternative D
compilers to keep up.
I'm aware of that, but I'm also aware of the crippling workarounds
cfront had to use to avoid changing *anything* in the back end, because
cfront had no control over them. There are still some suboptimal things
in C++ due to trying to avoid changing the rest of the tool chain.
While of course all this can be added to any back end, I understand how to
do it to mine, and it would take me a lot of time to understand another well
enough to be able to know just where to put the fix in.
That's understandable, but at some point it becomes worth the effort
to learn something new. Many people get by just fine using C++. They
may be interested in D, but it just takes too much effort. However, a
little effort invested in learning D pays off (at least we all believe
so or we wouldn't be here). Likewise, if there were a really solid
well-maintained back end with a liberal open source license that
generates great code, it would very likely be worth your time to learn
it, even though it might be rough going in the short term.
Such doesn't exist, however. I remember efforts back in the early 80's
to build one (the PCC, for example).
Another thing I'd be very unwilling to give up on with the dmd back end is
how fast it is. DMC is *still* by far the fastest compiler out there.
I'd gladly trade fast compilation for "has a future" or "supports
64-bit architectures" or "generates faster code" or "doesn't crash
when there are too many fixups in main()". Have you seen the
messages about how long it can take to compile DWT applications? DWT
progs are already desperately in need of some smarter dependency
tracking and ability to do minimal recompilations. I think
implementing that (in a build system or whatever) would more than make
up for the loss in raw compilation speed. Besides, I think a chunk of
the the compilation speed is thanks to the module system, and avoiding
the endless reparsing required for C++ #includes. So any D compiler
should benefit.
DMC is the fastest C/C++ compiler. DMD benefits from much of the work
that went in to make it fast. I did design the semantics of D to favor
fast parsing speeds, but there's still the back end speed which has
nothing to do with parsing semantics.
I found out yesterday that gcc still generates *text* assembler files
which are then fed to the assembler for all compiles. That just cannot
be made to be speed competitive.
Anyone have the data for the time required to compile tango with DMD
vs LDC? It would be interesting to see how bad the difference is.
Anyway, all that said, it's not clear that we really do have that
mythical "uber backend" available right now.
According to my conversations on the clang mailing list, the current
target is for LLVM to be able to fully support a C++ compiler by 2010.
I'm not quite sure what all that involves, but apparently it includes
things like making exceptions work on Windows. So it certainly does
look a bit premature to move over to LLVM as the primary platform for
D at this point.
Abandoning dmd's back end now then would entail a 2 year delay with no
updates, and I guarantee that there'll be years of wringing bugs out of
LLVM. Writing a cg for a complex instruction set like the x86 is, well,
pretty complicated <g> with thousands of special cases.
One thing that made D possible was I was able to use a mature,
professional quality, debugged optimizer and back end. The lack of that
has killed many otherwise promising languages in the past.
