Individual homework
#1 - #3 should be done and
turned in individually, not as a group.
- ASU 3.7abch. ("In order," or "in lexicographic order" means for
example that "p" preceeds "r", with or without arbitrary
intervening characters. You may not use the not operator
except for the simple case where not(a, b, ..., c) means
all single letters except the letters a, b, ... or
c.)
- ASU 3.16cd
- ASU 3.17 (for 3.16cd only) Be sure to use Algorithm 3.2.
Project
If you have formed a group, the following may be done by your group;
turn in only one solution per group.
To form a group, send email to Martha, mercaldi at cs, giving the
names and unix login of each group member. Max 3 persons per
group (2 recommended).
In this part of the project you will be extending the description of the PL/0 lexical
structure to include the new language features described in
the PL/0 Project Description.
In particular, note that the extensions will require the
scanner to handle
- Comments: A comment begins with double slashes ("//") and
extends to the end of the line. Comments are treated as
whitespace (not tokens).
- Underscores ("_") in identifiers: They may appear
anywhere that a letter can appear in an identifier.
- New reserved words:
else
,
for
,
to
,
continue
,
return
,
array
,
of
,
bool
,
true
,
false
,
and
,
or
.
[Note: don't use TRUE/FALSE as the token names for the Boolean
constants in the SYMBOL enum in token.h; those names conflict
with standard C #defines. Instead, I'd suggest
TRUETOKEN/FALSETOKEN.]
- New punctuation tokens:
[
and ]
.
Specifics:
- First, copy and build the base pl/0 compiler,
using the directions
here.
Test it on the sample program
here.
-
Extend the PL/0 scanner to scan the
extended language. Use the -T option to stop compiling after
scanning. You will also likely be interested in the
-t
option that prints tokens as they are read, and
perhaps the -c
(print characters) and
-l
(print lines) options.
For all implementation projects, you will be graded on
correctness of your implementation, on clarity and good design
of your implementation, and on sufficiency of your test cases.
See these pages for information on
printing and
electronically sumbitting your files
to us. Please read the turnin instructions carefully, so that
we get all the files we need and no other junk.
Optional, Extra Credit, Project Extension
If you can tell already that compilers are cool, and
you'd like to dig into it more, a modest number of extra
credit points and a significant number of techno-karma points
are to be had by implementing a substantive addition to PL/0:
add records (structs) to the language (a tiny step
towards PL/OO). You/your group get to design the syntax and
semantics, and carry through the implementation from scanner
through code generation. Ideally, you will turn in various
benchmark pieces of this in parallel with the regular
assignments, e.g. scanning now, parsing next time, etc., but we
can be a little flexible about the schedule. (You may also work
on extensions individually if your partner(s) aren't interested
in doing it. Please make this clear on your EC turnin so we
know. Also note that version control becomes a slightly bigger
deal in this case. Check out the facilities provided by RCS and
similar tools to help with this, e.g. to merge your EC scanner
code with your group's non-EC parser code.)
- What to do: start by designing your extensions.
Give us written descriptions of the syntax and semantics
that you intend to implement, at least at a level of detail
comparable to the
project description.
Where possible, try to think ahead to the types of
processing that will be required in later phases, such as
the sorts of legality checks that you'll need, issues of
scopes of names, parameter passing, storage allocation, etc.
Document them briefly. Obviously, I don't expect you to be
experts on all those things (until December 17th), but the point
is that there are actually a fair number of choices to be
made, and some of them will make your life much easier in
the later phases, so it pays to try to anticipate the key
issues.
-
What not to do: (a) Don't be overly ambitious about
what you decide to implement. E.g., records with overloaded
polymorphic multiple inheritance, while tempting, is perhaps
best left to students at schools on the semester system. (b)
Do NOT let work on the extensions interfere with finishing
the basic course requirements on time. I'd suggest you not
even think about the extensions until you've turned in a
clean, debugged version of the basic code, with test cases.
-
What to turn in: For this first turnin, give us
documentation for your planned extensions (see 1 above),
together with code and test cases for scanning. Next time, you
give us your parsing code, and test cases, etc. Also, if you
later decide to change any of your initial design specs, tell us
that, and sketch why ("We now realize that doing X will be way
easier than Y because it nicely fits in with Z" or whatever).
You may turn in your documentation on paper, but especially for
providing updated information in context with your turnin of future
phases, it might be easier to write your documentation online,
too. A plain text file, called Phase1Documentation.txt,
Phase2Documentation.txt, etc. is recommended. (We grade on
unix; Word files, e.g., are a pain.)
-
EC turnin is separate: You should first turn in your
compiler implementing the required functionality as described in
the Project section above. Then, after you have
implemented the EC additions and possibly added the
Phase1Documentation.txt file, turn in the compiler again by
following same instructions but running the following turnin
command instead:
turnin -c cse401 -p scannerEC pl0
It differs by the `-p scannerEC' option which will be announced
for each subsequent project part.
The TA and I will be happy to talk about any of these
design/implementation issues, so you don't need to dive in
blind.