These are based on old examination and practical questions:
(a) A BYT (Bright Young Thing) has been nibbling away at writing extensions to her first Parva compiler. It has been suggested that a function that will return the maximum element from a variable number of arguments would be a desirable addition, one that might form part of an expression as in
a = max(x, y, z) + 5 - max(a, max(c, d));
and that this could be achieved by extending the production for a Primary in a fairly obvious way, and adding a suitable opcode to the PVM. The production for Primary in the simple Parva compiler is defined as follows:
Primary<out int type> (. type = Entry.noType;
int size;
DesType des;
ConstRec con; .)
= Designator<out des> (. type = des.type;
switch (des.entry.kind) {
case Entry.Var:
CodeGen.dereference();
break;
case Entry.Con:
CodeGen.loadConstant(des.entry.value);
break;
default:
SemError("wrong kind of identifier");
break;
} .)
| Constant<out con> (. type = con.type;
CodeGen.loadConstant(con.value); .)
| "new" BasicType<out type> (. type++; .)
"[" Expression<out size> (. if (!isArith(size))
SemError("array size must be integer");
CodeGen.allocate(); .)
"]"
| "(" Expression<out type> ")" .
How would the Primary production and the interpreter need to be changed to support this extension?
Allow your max function to take one or more arguments, and ensure that it can only be applied to arithmetic arguments. Assume that a suitable CodeGen routine can be introduced to generate any new opcodes required.
(b) A BYT (Bright Young Thing) has been nibbling away at writing extensions to her first Parva compiler, while learning the Python language at the same time. She has been impressed by a Python feature which allows one to write multiple assignments into a single statement, as exemplified by
A, B = X + Y, 3 * List[6];
A, B = B, A; // exchange A and B
A, B = X + Y, 3, 5; // incorrect
which she correctly realises can be described by the context-free production
Designator { "," Designator } "=" Expression { "," Expression } ";"
The Parva attributed grammar that she has been given deals with single, simple integer assignments only (type checking not needed in the examination):
Assignment (. DesType des; .)
= Designator<out des> (. if (des.entry.kind != Entry.Var)
SemError("invalid assignment"); .)
"=" Expression (. CodeGen.assign(); .)
";" .
where the CodeGen.assign() method generates a code that is matched in the interpreter by a case arm reading
case PVM.sto:
// store value at top of stack on address at second on stack
mem[mem[cpu.sp + 1]] = mem[cpu.sp];
// bump stack pointer
cpu.sp = cpu.sp + 2;
break;
How would the Assignment production and the interpreter need to be changed to support this extension?
Go on to extend the system to incorporate type checking.
(c) Extend Parva to provide a relational operator for determining whether the value of an expression matched one of the values in a list, as exemplified by the following code
exp in (a, b, c)
itsASmallPrime = i in (2, 3, 5, 7, 11, 13);
if (list[i] in (i, 2 * i, 3 * i)) write("list[i] is a small multiple of its index");