General Information

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

Tutorials

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

Reference Manuals

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

Libraries

	Eli library routines
	Specification Module Library

Translation Tasks

	Lexical analysis specification
	Syntactic Analysis Manual
	Computation in Trees

Tools

	LIGA Control Language
	Debugging Information for LIDO
	Graphical ORder TOol

FunnelWeb User's Manual

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

Generating Unparsing Code

Monitoring a Processor's Execution

Administration

System Administration Guide

Oil Reference Manual

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.