You should talk with your classmates to form groups of two or three persons who will work together on the remaining phases of the project.
One student will be the Point of Contact (POC) and should send email to stewart@rohan.sdsu.edu listing the members of the group, with a cc: to other group members. Always using your class account. When you have Phase3 Integer Declarations (more info later) ready to be checked, the POC sends email to stewart@rohan.sdsu.edu with a Subject field indicating that CS 524 Phase 3 is ready to be checked and cc: to other group member class accounts.
I always get the simple.lex working first and see some new token being picked up and get simple.lr partially working - without any semantic actions so I can just watch the semantic stackdumps have the correct tags. (This means you have to change some *.h files too). Then you take the big plunge and implement the actions in sem.c - basically in the order they will be invoked by your grammar and whatever test data you choose to run. KEEP THE TEST DATA VERY SIMPLE AT FIRST - one line in a file is plenty.
My first test file (
q1
) consisted of the line: writeln ("hi");
My second test file (
q2
) was : writeln ("hi",x,y);
My third test file (
q3
) introduced printing ": writeln (" ""hi"" ");
As the semester progresses, the hints will not be this elaborate, but I want to be sure everyone gets started well.
This will be a good way to become familiar with the command line directives that you can use to control debugging output.
** Updated 15Feb08 **
simple.lex for Phase2. This include the module
strip quotes to assist you in learning the interface between your project,
the Unix tool lex and the process of recognizing the new token of a String Constant.
Note, although you are being given a routine to handle the scanning of strings, you still need to create for yourself the grammar that brings the String Constants into our Ada-like language.
You also must change simple.lr to include Strconst in the list of tokens (at the beginning of this file) which the parser (generated by yacc) expects to have returned by the scanner (generated by lex).
actparam : expr {createactparam();}
|
Strconst {pushstring(yytext);
createactparam();}
Reading section 3.4.2 on Lex, you see that the variable, yytext, is
the buffer that lex maintains and has the most recently scanned
input token.
You should also continue the corresponding call to lr_debug so that the simple -y option will give diagnostic output.
I used
pushstring()
{
}
The way I chose to implement strings used the global constant list Prog.const_listptr (declared in astdef.h and initialized InitSemantics in sem.c). Every time a string is encountered, it will be added to this constant list. The AST that is being built for a write statement (since that's the only place strings occur) has a paramlist for the items in the write. When the item is a string, then we need a pointer into the constant list indicating which string it is. You'll find several routines (discussed later in these notes) in codegen.c that manipulate information given a pointer to the constant list which are already written.
struct constlist *where
char *strconst; /* strconstentry */
You want to take the input string s and place it on the top of the semantic stack. Look at how pushid takes the identifier name and moves it to the semstack. You must allocate space for the string in the semstack and then change the tag to be strconstentry. Watch out how you had lex handle the string. If you use the example from the book, then the first and last " has been stripped off. When you get to the point of generating SPIM code, it will have to be
S1: .asciiz "whatever"
We already have a routine (constorage in codegen.c) that will traverse the global constant list and write this out - assuming it is given just the string which is the case when you've strip_quotes. You'll need to tidy things up (once you get everything else running) and make sure your listing file (s.list) has the same input, but don't worry about this at first.
Look at s.out - you already will have the new strings dumped out in the LABEL CONST section of the output SPIM code.
*** p.s. while you are in sem.c, I noticed a module (MergeAddOps) which is no longer invoked by the grammar and never used. So I would recommend removing this small module from sem.c
this will involve printparam