D is to be faulted for failing to avail itself of the back end tools that exist. I do not mean C!  I mean feeding a back end generator.  As a back end, C imposes its own peculiar constraints.  Neither direct Intel x86 assembly output nor C output are the optimum in terms of future-proofness, portability, maintainability, or speed of compiler development.  -M.



http://cs1.cs.nyu.edu/leunga/www/MLRISC/Doc/html/INTRO.html http://cs1.cs.nyu.edu/leunga/www/MLRISC/Doc/html/problem.html http://cs1.cs.nyu.edu/leunga/www/MLRISC/Doc/html/mltree.html

"Writing a native code generator for any language is a significant investment, especially for today's modern processors with require extensive compiler support to achieve high performance. The algorithms that must be used to generate high quality code are complex, sometimes quite delicate, and require substantial infrastructure.

"A specific architecture has a relatively short life time in relation to the time taken to build the code generator, and one quickly needs the ability to retarget to new versions of the architecture, or to different target architectures. This is by no means an open problem. There are many compilers today that target multiple architectures, however the quality of code varies. For example, lcc by Chris Fraser and David Hansen does no back end optimizations; gcc from the Free Software Foundation does extensive peephole and simple data flow optimizations, and falls short on advanced superscalar optimizations; and finally the IMPACT compiler done by the Impact group at the University of Illinois specializes in more advanced superscalar and predicated architectures.

"Assuming the retargeting issue is solved, one would like to use all the developed infrastructure for multiple source languages. This problem is far from solved; even though gcc has been used for multiple languages like Ada, Pascal, and Modula III, each of these have similiar execution models or were forced to adopt C conventions. gcc cannot be used directly for languages such as Lisp, Smalltalk, Haskell, or ML that have radically different execution models and special requirements to support advanced language features."

"Mark Evans" <Mark_member@pathlink.com> wrote in message news:bhlmir$2n7q$1@digitaldaemon.com...
>
> D is to be faulted for failing to avail itself of the back end tools that
exist.
> I do not mean C!  I mean feeding a back end generator.  As a back end, C
imposes
> its own peculiar constraints.  Neither direct Intel x86 assembly output
nor C
> output are the optimum in terms of future-proofness, portability, maintainability, or speed of compiler development.  -M.

You're right, it's a huge problem.