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 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., T2 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
- 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.