Eli   Documents Get Eli: Translator Construction Made Easy at SourceForge.net.
    Fast, secure and Free Open Source software downloads

General Information

 o Eli: Translator Construction Made Easy
 o Global Index
 o Frequently Asked Questions
 o Typical Eli Usage Errors


 o Quick Reference Card
 o Guide For new Eli Users
 o Release Notes of Eli
 o Tutorial on Name Analysis
 o Tutorial on Type Analysis
 o Typical Eli Usage Errors

Reference Manuals

 o User Interface
 o Eli products and parameters
 o LIDO Reference Manual
 o Typical Eli Usage Errors


 o Eli library routines
 o Specification Module Library

Translation Tasks

 o Lexical analysis specification
 o Syntactic Analysis Manual
 o Computation in Trees


 o LIGA Control Language
 o Debugging Information for LIDO
 o Graphical ORder TOol

 o FunnelWeb User's Manual

 o Pattern-based Text Generator
 o Property Definition Language
 o Operator Identification Language
 o Tree Grammar Specification Language
 o Command Line Processing
 o COLA Options Reference Manual

 o Generating Unparsing Code

 o Monitoring a Processor's Execution


 o System Administration Guide

Mail Home

Oil Reference Manual

Previous Chapter Next Chapter Table of Contents

Design Hints

Some `usual' problems in operator identification are presented with some suggested work-arounds using OIL(along with general guidelines for effective use of OIL.)

Incremental Design and Implementation

It is relatively easy to design and implement with OIL in incremental steps. One can work with the atomic/primitive types of your schema first and get the desired behavior with only identification. You can then add coercion sequence construction. And then work on the class specifications. Last of all one should work on compile time entity definition. These guide lines can be easily ignored but I would suggest that you find replacements for these rules rather than not do incremental design and implementation.

Identifying Operands

For some problems it is easier to identify the operand types and associated coercion sequences independently of the operator. When using OIL to select addressing modes for assembly language this is often the case as the instruction set is factored into operation and operand address. Operations can be factored into classes which support different operand address mode signatures. The classes can be defined as an indication and the different patterns of address modes are the strongly typed data flow operators for the instruction.

If we didn't use this method of `instruction classes' then we would have to duplicate the address mode patterns for each instruction in the class. This would be time consuming, redundant, and a strain on our name generation faculties. And such a multiplicity of names would cause its own confusion, reducing the benefit of using OIL.

Error Handling

There are two ways to handle errors with OIL: use your own error type and use OIL's. Each has its own advantages.

OIL's error type is OilInvalidType and is by definition coercible to and from any type. Thus once an expression is assigned this value it will make an end-run on OIL's strong typing and match any operator which satisfies the other argument constraints. In the degenerate case where all operands are OilInvalidType then any identifiable operator will be chosen.

If your own type is used(say ErrorType) you must define an operator with it in its signature(the only way to define a type other than class instantiation.) By not having any type coercible to it no operator will be identified and thus no valid operator will be returned and the function OilIsValidOp will return false allowing easy error detection.

The error operator(OilInvalidOp) has a type signature of all OilInvalidType. Thus if it is identified, which in the error case it is, no type errors will be propagated up or down the tree.

Modeling OIL's function

If you need to model OIL in your compiler design, one of the most convenient ways is to consider the set of declarations which the OIL library manages as a database. This data base is initialized by the OIL specification and modified and accessed via the library functions.

Schema Restrictions

OIL has a very simple schema model. All of the library routines only add declarations to an OIL schema. There is no way to remove a declaration from an OIL schema once it has been added. This can have two impacts on your use of OIL. Every added declaration increases the cost of an identification which it may impact. Once an identification is added to the schema it may satisfy an identification request, the only way to prevent it is to control what kinds of requests are made.

Identification Algorithm

OIL has a two level search strategy: minimum cost identification and if costs are equal the most recent identification added to the schema.

Previous Chapter Next Chapter Table of Contents