www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D compiler layers

reply bearophile <bearophileHUGS lycos.com> writes:
(This comes from things that Lindquist has vaguely said, but I am not sure).

I am very ignorant about this topic still, so I can be quite wrong, but I think
it can be positive to split the D2 front-end in two layers, to simplify the
creation of D compilers:
1) A true front-end layer that's almost independant, that can be adapted to
different back-ends;
2) A middle-layer that performs some higher-order operations, like run-time
execution of functions, certain high level optimizations (like pure function
optimizations like pulling pure functions out of loops, and eventually some
delegate inlining), that can be missing in the DMD backend but already present
in LLVM. Such operations need to know semantics about the code, so LLVM by
itself may be unable to perform them.

So when you try to use LLVM to compile D code you don't touch the true
front-end, and you replace some of the parts of the middle layer with things
already present in LLVM.

Bye,
bearophile
Nov 25 2009
parent reply Tim Matthews <tim.matthews7 gmail.com> writes:
bearophile wrote:
 (This comes from things that Lindquist has vaguely said, but I am not sure).
 
 I am very ignorant about this topic still, so I can be quite wrong, but I
think it can be positive to split the D2 front-end in two layers, to simplify
the creation of D compilers:
 1) A true front-end layer that's almost independant, that can be adapted to
different back-ends;
 2) A middle-layer that performs some higher-order operations, like run-time
execution of functions, certain high level optimizations (like pure function
optimizations like pulling pure functions out of loops, and eventually some
delegate inlining), that can be missing in the DMD backend but already present
in LLVM. Such operations need to know semantics about the code, so LLVM by
itself may be unable to perform them.
 
 So when you try to use LLVM to compile D code you don't touch the true
front-end, and you replace some of the parts of the middle layer with things
already present in LLVM.
 
 Bye,
 bearophile

Some simple lessons can be learnt from the clang project. Clang is designed as a bunch of separate libraries so they can be used for anything that needs to process c. http://clang.llvm.org/features.html#libraryarch In my opinion there should be one set of libraries (not limited to 2 layers) that is generalized enough to be used by any compiler, ide or other tools for d too. Not too long ago I noticed yet another "I've made a d ide" post. The problem is that similar code used by other ides, and compilers is re written again every time and each have a long life of bug fixing until they can read the majority of d code and still have its flaws. D.R.Y (don't repeat yourself). Even M$ is a victim of this when visual studio ide thinks your C++ code is in error but the compiler handles it just fine.
Nov 25 2009
next sibling parent retard <re tard.com.invalid> writes:
Thu, 26 Nov 2009 16:22:26 +1300, Tim Matthews wrote:

 In my opinion there should be one set of libraries (not limited to 2
 layers) that is generalized enough to be used by any compiler, ide or
 other tools for d too.
 
 Not too long ago I noticed yet another "I've made a d ide" post. The
 problem is that similar code used by other ides, and compilers is re
 written again every time and each have a long life of bug fixing until
 they can read the majority of d code and still have its flaws.
 
 D.R.Y (don't repeat yourself). Even M$ is a victim of this when visual
 studio ide thinks your C++ code is in error but the compiler handles it
 just fine.

But many of us use D as a hobby and attend basic compiler construction classes at schools even as we speak. It would be boresome to use existing code and wouldn't boost the learning process. It's also very common that the implementation languages or the licenses differs. A set of libraries would have to be written in some portable language like C. Most of us want to use D instead. Some of us like BSD, some GPL, and a small part even develops proprietary tools for D. Some might say that it's even benefical to have a rich set of tools - if you run into ICE, another D compiler/IDE might not fall into that trap. It also helps fixing the spec since currently it's not possible to develop two nearly identical compilers (without using dmdfe) because even dmd violates the spec in many cases. And when you ask Walter how it / should/ work, he remains silent (for instance in the case of protection attributes when inheriting from a base class - class foo : protected bar)
Nov 26 2009
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
Tim Matthews:
 In my opinion there should be one set of libraries (not limited to 2 
 layers) that is generalized enough to be used by any compiler, ide or 
 other tools for d too.

I know, Clang design is probably better. But it's a very different design. What I am asking is an improvement of the current D2 front-end code to allow its better usage with the LLVM backend. I'm asking to separate better the compilation phases. Bye, bearophile
Nov 26 2009