A lot of the following material is the result of discussion with several people, including, but not limited to3:
Benoît Perrot, Raphaël Poss,
Alexis Brouard, Sébastien Broussaud (Darks Bob), Stéphane Molina (Kain), William Fink,
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 LRDE.
|TC-0||Friday, January 24th 2003 12:00|
|TC-1||Friday, February 14th 2003 12:00|
|TC-2||Friday, March 14th 2003 12:00|
|TC-4||Friday, April 25th 2003 12:00|
|TC-3||Rush from Saturday, May 24th at 18:00 to Sunday 12:00|
|TC-56||Friday, June 20th 2003, 12:00|
|TC-7||Friday, July 4th 2003 12:00|
|TC-78||Friday, July 18th 2003 12:00|
|TC-9||Monday, September 8th 2003 12:00|
Criticisms about Tiger 2005 include:
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 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
Cannot be solved, see Tiger 2003.
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
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.
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, and TC-5), 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).
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:
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.
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.
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.
Please, let us know whom we forgot!