• bearophile (23/23) Jul 05 2009 D contains few features that make it not easy for LDC developers create ...

bearophile <bearophileHUGS lycos.com> writes:

D contains few features that make it not easy for LDC developers create a
compiler that fully follows D specs. LDC developers have solved some of those,
and maybe as LLVM improves few more may be solved in future. This lists most of
them:
http://www.dsource.org/projects/ldc/wiki/Docs#Violationsofthespecification

Like:

- Inline assembler:  For labels inside inline asm blocks, the D spec says "They
can be the target of goto statements.", this is not supported at the moment.
Basically, LLVM does not allow jumping in to or out of an asm block. We work
around this for jumping out of asm by converting these branches to assignments
to a temporary that is then used in a switch statement right after the inline
asm block to jump to the final destination. This same workaround could be
applied for jumping into inline assembly.

- The D spec says that T[0] val; does not require storage but has an address.
LDC currently allocates one bit for such a construct.

So it may be better to think about such D features, and think if they aren't so
important, so they can be removed to D specs, to help LDC to be a correct
implementation of D1 (and in future D2).

---------

But it can also be quite interesting to look at the situation from the opposite
point of view. Currently LLVM offers some features (that are probably missing
in the backend of DMD) that aren't present in D specs, but being them already
implemented, adding them to D is cheap. For example:
- inline asm intrinsics that allow smarter management of input-output CPU
registers, this allows to write faster inline asm.
- a way to inline (in a not safe way) functions that contain asm (this can be
done by DMD too, I guess)
- run time tests to find integer overflows
(http://llvm.org/docs/LangRef.html#int_overflow )
- having a compiler that can be used as a dll, for example to compile code at
runtime, to have a standard built-in D REPL (shell) to try D code
interactively, and for some other things. This may turn out to be a strong
advantage of D over C/C++, yet D developers seem uninterested to such big
possibilities.
- computed gotos (http://clang.llvm.org/doxygen/classclang_1_1GRIndirect
otoNodeBuilder.html ), that are useful to me too.
- runtime stack protection with stack canaries (useful in nonrelease mode or
for safeD) (-stack-protector).
- analysis of the inheritance to de-virtualize class methods.
- ways to state that pointer aliasing isn't happening.
- llvm offers even built-in multi-precision integers.
- support for optimization tricks like __builtin_expect() of GCC that sometimes
are useful, in my programs too (this can probably be done in DMD too, but it's
not present in D specs).
- There are surely other things I have missed.

Some of those things were suggested to be added to the D language, but they
were refused also because they require work to be implemented (like the
compiler as DLL, computed gotos and more), but now such refusals don't hold
anymore because LLVM has such capabilities, and it's "just" a matter of
defining a syntax, adding that to D specs, and then using them...

So, while at the moment there's no LDC D2 compiler yet, D2 specs can take in
account that LDC may eventually become the most used D compiler, so it can be
much better to use the good things LLVM offers, instead of limiting D2 specs to
just the capabilities of the old back-end of DMD :-)

Bye,
bearophile