FAQ
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?
-
Sure!
- 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)