Noeud « Next »: , Noeud « Previous »: Tiger 2004, Noeud « Up »: History



1.4.5 Tiger 2005

A lot of the following material is the result of discussion with several people, including, but not limited to1:

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 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 lrde.

Deliveries were:

T0 Friday, January 24th 2003 at noon
T1 Friday, February 14th 2003 at noon
T2 Friday, March 14th 2003 at noon
T4 Friday, April 25th 2003 at noon
T3 Rush from Saturday, May 24th at 18:00 to Sunday at noon
T56 Friday, June 20th 2003, at noon
T7 Friday, July 4th 2003 at noon
T78 Friday, July 18th 2003 at noon
T9 Monday, September 8th 2003 at noon

Criticisms about Tiger 2005 include:

Too many memory leaks
Voir 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, denunciate 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, and make sure you 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 (voir 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/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.

Upgraded tarballs don't compile
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 (voir History) and that dedicated to coding style (voir 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 T3, and T5), 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 T2 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 computation of the escapes is too hard
The computation of the escapes is too easy
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 T5), many students are deadly lost.

We are considering splitting T5 into two: T5- which would be limited to programs without escaping variables, and T5+ 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 (voir Use of Foreign Features). Hints at possible extensions are provided, and finally, alternative implementation are suggested for each stage, for instance see T2 Improvements.

Notes de bas de page

[1] Please, let me know who I forgot!