No subject

compiler.  Please understand that this is mostly my OPINION, not necessarily the truth or 
even the best way to do things.  Feel free to disagree (but please do so constructively!).

COMPILER STAGES:

The compiler consists of several stages of operation.  It is possible in describing a 
compiler to state that the stages occur sequentially without over simplification.  In actual 
operation, the various stages are tied together and they operate in an interleaved fashion; 
the compiler driver controls this interoperation.

THE DRIVER
 
The compiler driver is a simple construct that creates the user-interface of the compiler.  
It is responsible for parsing the command line parameters and for printing status and error 
messages.

THE SCANNER:

The scanner is actually a multiple function component.  It is responsible for reading a 
stream of text characters from storage and providing a stream of tokens to the parser.

The initial stream of text may come from multiple files by use of the {$I <filename>} 
directive.

Much like the preprocessor directives of the C language, Object Pascal uses compiler 
directives to modify the behavior of the compiler.  The capability of the OP6 language 
does not provide any method of text replacement or macros, but does provide conditional 
compilation.  The scanner needs to be able to enable or disable blocks of text based on 
compiler directives.

In addition, the compiler directives can be used to override the command line options.

For error reporting, it is necessary that the tokens returned by the scanner have the file 
name, line number and character position of the original text that generated the token.

Tokens should also contain the text of the token, a value and a token type.

THE PARSER:

The parser definition (I'm assuming that it will be a Jay generated parser!) needs to be 
kept as slim and readable as possible.

Due to the namespace feature and out-of-order compile nature of C#, it is possible to 
build a set of helper routines fairly easily and just use simple calls to the helper routines 
in the definition file.

These helper routines should ideally be a part of the parse-tree component.

THE PARSE-TREE:

The parse-tree is a simple data structure that encapsulates the form of the text being 
compiled in a syntactically and (mostly) semantically correct fashion.  

The parse-tree is built from individual node elements.  Each class of element is defined to 
encapsulate one specific semantic concept of the Object Pascal language and is used to 
contain only structures that match.  When the parser tries to build a structure in the parse-
tree that is incorrect, an error can be flagged.

During the first portion of the compile process, the scanner and parser work to fill the 
parse-tree.

Once the tree is built, the driver can (optionally) cause an optimization pass to improve 
the performance of the structure.  (Not my area!  I've studied it, but it still doesn't make 
much sense to me!
Following the optimization pass, the parse-tree is traversed in order to generate code.  
Because each node of the tree embodies a specific semantic concept, the node can 
generate appropriate code to implement that concept.  Any contained nodes are simply 
called to generate their own code in the appropriate order.

NOTE:

It looks like I've chopped off the sequence of the compiler in kind of non-standard way.  
That's just me thinking ahead and forgetting to write what I'm thinking… ?

OBJECT PASCAL NOTES:

Unlike the C family of languages, Object Pascal enforces a rigid structure on compilation 
units.  A Pascal UNIT is a file that can be compiled to an object file,  

The structure of a UNIT is that is an interface definition and an implementation of that 
interface.  This is NOT the concept of classes and interfaces from object oriented 
programming, although it is quite similar.

To compile a group of Pascal UNIT files, it is often necessary to know the interface of 
one UNIT before that unit can be compiled (mutual dependencies).  This is entirely legal 
according the language specification.  

To enable compilation of these units requires that the interface of a unit can be compiled 
separately from the implementation.  Some implementations do this by compiling the unit 
interface to a symbol file and then producing a second object file.  Other implementations 
provide both symbol and object information in the same file.

The practical result of this issue is that the compiler must be able to compile an interface 
of a unit and create a symbol file for that unit, even if the remainder of the unit cannot be 
compiled.

A second part of the Pascal Unit is that the dependencies for the unit are explicit.  Pascal 
is strict about declaring elements before they are used.  This means that the compiler 
must know what an element is before it can compile code to use that element.

What this means is that when the compiler reaches the USES statement in a file, it will 
attempt to load the symbol information for the referenced UNIT.  A USES statement is 
how Object Pascal imports UNIT files.

When attempting to load a unit's symbol file, a process similar to the make program is 
used.  If a symbol file exists, but the source file does not, the symbol file is loaded.  If a 
source file exists and is newer than the symbol file, then it is re-compiled.  If a source file 
exists and no symbol file exists, then it is compiled.

What does this mean to us?  Our compiler MUST BE ABLE to suspend compiling one 
source file, compile another, and then resume the first file.  This must be able to happen 
to an arbitrary depth of recursion.  Some older commercial Pascal compilers limited this 
to a depth of 16 files.  In addition, due to the mutual dependence requirements mentioned 
above, it is necessary for the compiler to be able to compile an interface of a UNIT and 
then abort without error to resume the first file.  When this happens, it is necessary for the 
aborted unit to be re-compiled completely at some later time when the prerequisite units 
have all been compiled.

It is a complex issue, but is part of the standard so we need to take care of it.



OK,

That's enough blather for now.

Comments to the mono-devel mailing list please (mono-devel-list at lists.ximian.com).
 
Thanks,
 
--Grant

--------------090909040302030503050700--