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

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.

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

Generated by mltex2html
Last modified: Mon Oct 3 20:52:35 UTC 2022 by buildd@x86-grnet-02