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

# Instructions

Instructions

Predication VLIW Predicated VLIW

Instructions in MLRISC are implemented as abstract datatypes and must satisfy the signature INSTRUCTIONS, defined as follows:

     signature INSTRUCTIONS =
     sig
        structure C        : CELLS
        structure Constant : CONSTANT
        structure LabelExp : LABELEXP
           sharing LabelExp.Constant = Constant

        type operand
        type ea
        type addressing_mode
        type instruction
     end

Type `operand` is used to represent ioperands, `ea` is used to represent effective addresses, type `addressing_mode` is used to represent the internal addressing mode used by the architecture. Note that these are all abstract according to the signature, so the client has complete freedom in choosing the most convenient representation for these things.

## Predication

For architectures that have full predication built-in, such as the C6xx or IA-64, the instruction set should be extended to satisfy the signature:

     signature PREDICATED_INSTRUCTIONS =
     sig
        include INSTRUCTIONS

        type predicate
     end

This basically says that the type that is used to represent a predicate can be implemented however the client wants. This flexibility is quite important since the predication model may differ substantially from architecture to architecture.

For example, in the TI C6, there are no seperate predicate register files and integer registers double as predicate registers, and the predicate true is any non-zero value. Each instruction can be predicated under a predicate register or its negation. In contrasts, architectures such as IA-64 and HP's Playdoh incorporate separate predicate registers into their architectures. In Playdoh, predicate defining instructions actually set a pair of complementary predicate registers, and instructions can only be predicated under the value of a predicate register, not its negation.

## VLIW

VLIW architectures differ from superscalars in that resource assignments are statically determined at compile time. We distinguish between two different types of resources, namely functional units and data paths. The latter type is particularly important for clustered architectures. The following signature is used to describe VLIW instructions:

     signature VLIW_INSTRUCTIONS =
     sig

        include INSTRUCTIONS
        structure FU : FUNITS
        structure DP : DATAPATHS
     end

The signature `FUNITS` is used to describe functional unit resources, while the signature `DATAPATHS` is used to describe data paths.

## Predicated VLIW

Finally, instructions sets for predicated VLIW/EPIC machines should match the signature

     signature PREDICATED_VLIW_INSTRUCTIONS =
     sig
        include VLIW_INSTRUCTIONS
        type predicate
     end

Lal George
Allen Leung

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