Tiger 2005

A lot of the following material is the result of discussion with several people, including, but not limited to [1]

Comaintainers: Benoît Perrot, Raphaël Poss,
Assistants: Alexis Brouard, Sébastien Broussaud (Darks Bob), Stéphane Molina (Kain), William Fink,
Students: Claire Calméjane, David Mancel, Fabrice Hesling, Michel Loiseleur.

I (Akim) here thank all the people who participated to this edition of this project. It has been a wonderful vintage, thanks to the students, the assistants, and the members of the LRE.

Deliveries were:

Stage	Submission
TC-0	Friday, January 24th 2003 at noon
TC-1	Friday, February 14th 2003 at noon
TC-2	Friday, March 14th 2003 at noon
TC-4	Friday, April 25th 2003 at noon
TC-3	Rush from Saturday, May 24th at to Sunday
TC-56	Friday, June 20th 2003 at noon
TC-7	Monday, July 4th 2003 at noon
TC-78	Friday, July 18th 2003 at noon
TC-9	Friday, September 8th 2003 at noon

Criticisms about Tiger 2005 include:

Too many memory leaks

See Tiger 2004. This is the most significant failure of Tiger as an instructional project: we ought to demonstrate the proper memory management in big project, and instead we demonstrate laziness. Please, criticize us, denounce us, but do not reproduce the same errors.

The factors that had pushed to a weak memory management is mainly a lack of coordination between developers: we should have written more things. So don’t do as we did: define the memory management policy for each module, and write it.

The 2006 edition pays strict attention to memory allocation.

Too long to compile

Too much code was in *.hh files. Since then the policy wrt file contents was defined (See File Conventions), and in Tiger 2006 was adjusted to obey these conventions. Unfortunately, although the improvement was significant, it was not measured precisely.

The interfaces between modules have also been cleaned to avoid excessive inter dependencies. Also, when possible, opaque types are used to avoid additional includes. Each module exports forward declarations in a fwd.hh file to promote this. For instance, ast/tasks.hh today includes:

// Forward declarations of ast:: items.
#include "ast/fwd.hh"
// ...
    /// Global root node of abstract syntax tree.
    extern ast::Exp* the_program;
// ...

where it used to include all the AST headers to define exactly the type ast::Exp.

Filling holes is not interesting

Cannot be solved, see Tiger 2003.

No written conventions

Since its inception, the Tiger Compiler Project lacked this very section (See History) and that dedicated to coding style (See Coding Style) until the debriefing of 2005. As a result, some students or even so co-developers of our own tc reproduced errors of the past, changed something for lack of understanding, slightly broke the homogeneity of the coding style etc. Do not make the same mistake: write down your policy.

The AST is too poor

One would like to insert annotations in the AST, say whether a variable is escaping (to know whether it cannot be in a register, see TC-3, Bindings, and TC-5, Translating to the High Level Intermediate Representation), or whether the left hand side of an assignment in Void (in which case the translation must not issue an actual assignment), or whether ‘a < b’ is about strings (in which case the translation will issue a hidden call to strcmp), or the type of a variable (needed when implementing object oriented Tiger), etc., etc.

As you can see, the list is virtually infinite. So we would need an extensible system of annotation of the AST. As of September 2003 no solution has been chosen. But we must be cautious not to complicate TC-2 too much (it is already a very steep step).

People don’t learn enough C++

It seems that the goal of learning object oriented programming and C++ is sometimes hidden behind the difficult understanding of the Tiger compiler itself. Sometimes students just fill the holes.

To avoid this:

The holes will be bigger (conflicting with the ease to compile something, of course) to avoid any mechanical answering.
Each stage is now labeled with its “goals” (e.g., TC-2 Goals) that should help students to understand what is expected from them, and examiners to ask the appropriate questions.

The computation of the escapes is too hard

If you understood what it means that a variable escapes, then the implementation is so straightforward that it’s almost boring. If you didn’t understand it, you’re dead. Because the understanding of escapes needs a good understanding of the stack management (explained more in details way afterward, during TC-5), many students are deadly lost.

We are considering splitting TC-5 into two: TC-5- which would be limited to programs without escaping variables, and TC-5+ with escaping variables and the computation of the escapes.

The static-link optimization pass is improperly documented

Todo.

The use of references is confusing

We used to utilize references instead of pointers when the arity of the relation is one; in other words, we used pointers iff 0 was a valid value, and references otherwise. This is nice and clean, but unfortunately it caused great confusion amongst students (who were puzzled before *new, and, worse yet, ended believing that’s the only way to instantiate objects, even automatic!), and also confused some of the maintainers (for whom a reference does not propagate the responsibility wrt memory allocation/deallocation).

Since Tiger 2006, the coding style enforces a more conventional style.

Not enough freedom

The fact that the modelisation is already settled, together with the extensive skeletons, results in too tight a space for a programmer to experiment alternatives. We try to break these bounds for those who want by providing a generic interface: if you comply with it, you may interchange with your full re-implementation. We also (now explicitly) allow the use of a different tool set. Hints at possible extensions are provided, and finally, alternative implementation are suggested for each stage, for instance see TC-2 Improvements.

Footnotes