MLRISC
MLRISC
Contributors
Requirements
How to Obtain MLRISC
Overview
Problem Statement
Contributions
MLRISC Based Compiler
MLRISC Intermediate Representation
MLRisc Generation
Back End Optimizations
Register Allocation
Machine Description
Garbage Collection Safety
System Integration
Optimizations
Graphical Interface
Line Counts
Systems Using MLRISC
Future Work
System
Architecture of MLRISC
The MLTREE Language
MLTree Extensions
MLTree Utilities
Instruction Selection
Assemblers
Machine Code Emitters
Delay Slot Filling
Span Dependency Resolution
The Graph Library
The Graph Visualization Library
Basic Compiler Graphs
The MLRISC IR
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
Annotations
Cells
Cluster
Client Defined Constants
Client Defined Pseudo Ops
Instructions
Instruction Streams
Label Expressions
Labels
Regions
Regmap

System Integration


In a heavily parameterized system like this, one very quickly ends up with a large number of modules and dependencies making it very easy to mix things up in the wrong way. module dependencies
For example, MLRisc is parameterised over pseudo-ops, constants, and regions. An instruction set must be parameterized over constants so that instructions that carry immediate operands can also carry these abstract constants. Instructions must also be parameterized over regions so that memory operations can be appropriately annotated. Finally, the flowgraph module must be parameterized over instructions it carries in basic blocks and pseudo-ops that describe data layout and alignment constraints.

sharing constraints
In integrating a system that involves these modules, it must be the case that they were created with the same base modules. That is to say the pseudo-ops in flowgraphs must be the same abstraction that was used to define the MLRisc intermediate representation. Alternatively, we want sharing constraints that assert that identity of modules used to specialize other modules. In Standard ML, this is a complete non-issue. A single line that says exactly that is all that is needed to maintain consistency, and the module system does the rest to ensure that the final system is built correctly.

Back end optimizations
In certain cases one wants to write a specific module for a particular architecture. For instance it may be desirable to collapse trap barriers on the DEC Alpha where it is legal to do so. The INSTRUCTIONS interface is abstract with no built-in knowledge of trap barriers as not all architectures have them. Further the DEC Alpha has fairly unique trap barrier semantics, that one may want to write an optimization module specific and dedicated to the Alpha instruction set and architecture, and forget about writing anything generic. In this case, the Standard ML module system allows one to say that a specific abstraction actually is or matches a more detailed interface. That is to say the INSTRUCTION interface is really the DEC Alpha instruction set.


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