This page will be updated throughout the course when relevant.

Note that questions related to the exam can be found on a separate page via the exam page, or via this direct link.

I use the flag "-lfl", so why won't my Flex program compile?
It says in the Flex documentation that you should link to Flex when compiling the C-program it has created, i.e., give gcc the flag -lfl. However, this does not seem to be necessary and may give more problems than it solves. Among other things, libfl.a defines a main function. So if you have defined a main function yourself, it won't compile. Consider not using that flag.

Why does Flex keep complaining about "yywrap"?
Flex wants you to define a yywrap function to tell Flex what to do when it has read through the (first) input file. This function is often not needed; partly because there's often just one input file. One way to stop the complaining is to write %option noyywrap in the top of your .lex file.

Bison indicates a default case, but it is not using it!
When considering the .output file, which Bison can generate for debugging purposes, some states end with a default statement. However, this should be read as an "otherwise" in a case statement, where the other cases consist of the listed next symbols on input. For a concrete next symbol on input, the action which is taken is the one not enclosed in square brackets.

Can we have the LaTeX source code for the Tigris grammar?

How do we make Bison handle operator precedence when all operators just come from Flex as values associated with op?
That is not an entirely unreasonable way to read the project description, since this is similar to how num and id are handled. However, my intention was actually that you should replace the production <expression> : <expression> op <expression> in the grammar with one production for each of the operator symbols that op can be, i.e., there should be <expression> : <expression> '+' <expression>, <expression> : <expression> '-' <expression>, etc.

Can we have some example Tigris programs to look at?
Yes! Some are available in the directory /home/IMADA/courses/dm18/ along with a check program, check.py. See the beginning of the file check.py for how to use the program.

For the heap implementation, are we allowed to use malloc or other system calls?
The intention is that you should experience managing a heap area yourself. Thus, you must allocate a large amount of memory at start-up and then handle memory allocation explicitly in your compiler. This means, as a starting point, that a user program can run out of memory. You could have a check for this and terminate in a controlled fashion if it happens. You can allocate the large amount of memory using the technique demonstrated in the example GNU assembler program on global variables. It is also allowed to make one (1) call to malloc to allocate this large amount of memory once and for all. Thus, calls to malloc or other systems call in connection with every memory allocation for records and arrays is not accepted. More than one call to malloc can be accepted if it is carried within the spirit of the above. For instance, you may allocate a large amount of memory with malloc at start-up and whenever you run out of memory, allocate an additional large amount of memory using malloc again. The important issue is that you demonstrate that you can manage a heap yourself.

In the report template, what do you mean by "resources"?
"Resources" appears in the phase diagram that I've used because in some situations for compilers in general, this can be an important phase. Resources include the amount of space you need or anything else which might be limited. For multi-process programs, it could include the number of processers required. For jobs released to a Grid-system, it could be the number of machines of a certain architecure requested to carry out a given job. In the case of our programming language, space is the only really interesting resource, and one would naturally assume that there is enough. It is fine to omit that section from the report.

Last modified: Thu May 10 11:23:20 CEST 2007
Kim Skak Larsen (kslarsen@imada.sdu.dk)