View mode: basic / threaded / horizontal-split · Log in · Help
August 16, 2003
MLRISC
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."
August 18, 2003
Re: MLRISC
"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.
Top | Discussion index | About this forum | D home