How to Obtain MLRISC
Problem Statement
MLRISC Based Compiler
MLRISC Intermediate Representation
MLRisc Generation
Back End Optimizations
Register Allocation
Machine Description
Garbage Collection Safety
System Integration
Graphical Interface
Line Counts
Systems Using MLRISC
Future Work
Architecture of MLRISC
The MLTREE Language
MLTree Extensions
MLTree Utilities
Instruction Selection
Machine Code Emitters
Delay Slot Filling
Span Dependency Resolution
The Graph Library
The Graph Visualization Library
Basic Compiler Graphs
SSA Optimizations
ILP Optimizations
Optimizations for VLIW/EPIC Architectur...
Register Allocator
Back Ends
The Alpha Back End
The PA RISC Back End
The Sparc Back End
The Intel x86 Back End
The PowerPC Back End
The MIPS Back End
The TI C6x Back End
Basic Types
Client Defined Constants
Client Defined Pseudo Ops
Instruction Streams
Label Expressions

Problem Statement

Writing a native code generator for any language is a significant investment, especially for todays 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.

Retargeting compiler 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.

UNCOL? 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.

Lal George
Allen Leung
SML/NJ Validate this page
Generated by mltex2html
Last modified: Thu Jan 9 19:38:15 EST 2003 by leunga@slinky