These problems are taken from several quizes held over the years, and just probe various techniques useful in developing applications with Coco.
1. In the compiler studied in the course the following Cocol code was used for a WhileStatement:
WhileStatement<StackFrame frame> (. Label startLoop = new Label(known); .)
= "while" "(" Condition ")" (. Label loopExit = new Label(!known);
CodeGen.branchFalse(loopExit); .)
Statement<frame> (. CodeGen.branch(startLoop);
loopExit.here(); .)
.
This generates code that matches the outline
startLoop: Condition
BZE loopExit
Statement
BRN startLoop
loopExit:
Some authors contend that it would be preferable to generate code that matches the outline
BRN testlabel
startLoop: Statement
testlabel: Condition
BNZ startLoop
Their argument is that in most situations a loop body is executed many times, and that the efficiency of the system will be markedly improved by executing only one branch instruction on each iteration.
(a) Do you think the claim is justified for an interpreted system such as we have used? Explain your reasoning.
(b) If the suggestion is easily implementable in terms of our code generating functions, show how this could be done. If it is not easily implementable, why not?
2. In the compiler you (should) have developed to allow for characters as well as integers and booleans it was suggested that you use C-like syntax for casting, for example
int i = 60;
char c = (char) (4 + i);
c = (char) (int) 'a';
i = (int) c + 45
In Modula-2, what amounts to casting operations uses a syntax exemplified by
i = 60;
c = CHAR(4 + i);
c = CHAR( INTEGER('a') );
i = INTEGER(c) + 45;
How would you alter your compiler to use this latter approach. Which strikes you as "better"? Justify your answer.
3. The original Parva grammar in chapter 14 of the text book defines expressions as follows (note that this incorporates the idea of allowing "function calls" as part of an expression, which we did not cover in Practical 25):
Expression = AddExp [ RelOp AddExp ] .
AddExp = [ "+" | "-" ] Term { AddOp Term } .
Term = Factor { MulOp Factor } .
Factor = Designator [ "(" Arguments ")" ]
| Constant
| "new" BasicType "[" Expression "]"
| "!" Factor
| "(" Expression ")" .
What, if anything, would be the difference if this were replaced by
Expression = AddExp [ RelOp AddExp ] .
AddExp = Term { AddOp Term } .
Term = Factor { MulOp Factor } .
Factor = Designator [ "(" Arguments ")" ]
| Constant
| "new" BasicType "[" Expression "]"
| "!" Factor
| "+" Factor
| "-" Factor
| "(" Expression ")" .
4. Here is a true story. A few years ago I received an e-mail from one of the many users of Coco/R in the world. He was looking for advice on how best to write Cocol productions that would describe a situation in which one non-terminal A could derive four other non-terminals W, X, Y, Z. These could appear in any order in the sentential form, but there was a restriction that each one of the four had to appear exactly once. He had realised that he could enumerate all 24 possibilities, on the lines of
A = W X Y Z | W X Z Y | W Y X Z | ....
but observed very astutely that this was very tedious, and also would become extremely tedious if one were to be faced with a more general situation in which one non-terminal could derive N alternatives, which could appear in order but subject to the restriction that each should appear once.
Write the appropriate parts of a Cocol specification that will describe the situation and check that the restrictions are correctly met. (Restrict your answer to the case of 4 derived non-terminals, as above.)
5. As you should know, if one wishes to let line ends become significant in Cocol grammars one resorts to writing code like
CHARACTERS
LF = CHR(10).
TOKENS
EOL = LF .
It would not be very difficult - and it might be deemed an improvement - to modify Coco/R to allow for LF and EOL to become "key words" (just as ANY and EOF are key words).
Coco/R is itself defined by a Cocol grammar, and, like the compilers you have just worked with, this can be used to create the scanner, parser and driver classes, which are then compiled along with the classes that handle symbol tables and other data structures. Give a T-diagram representation of how one could produce a new Java version of Coco/R that incorporates the new features.
6. Given that you had access to this new version of Coco/R. how would you modify the Parva grammar so that at the end of compilation it could tell you how many lines of source code had been compiled?
7. Here is another true story. Some years ago a group of third year Rhodes students formed a team for one of the ACM programming competitions. One of the problems was quite clearly one for which their knowledge of Coco/R meant they could write a simple grammar and literally solve it within minutes. Unfortunately, solutions had to be able to read from standard input and write to standard output, so that they could be tested with (hidden) data by giving a command like
java -jar Solution.jar <data >results
Standard Coco requires that the input file name be supplied as a command line parameter
java -jar Solution.jar data >results
Time did not permit them to modify Coco/R. Given that you have some time, suggest howe could produce a version of Coco/R suited to solving ACM competition problems.