CSE 131B – Compiler Construction II

Discussion 3: Project 1 – Constants, Type Aliases, Procedures

1/24/2007

Overview

Constants

Type Aliases

Procedures

Topics/Questions you may have

Constants

CONST c = 5; (* INTEGER *) CONST d = 5.0; (* REAL *) CONST e = FALSE; (* BOOLEAN *) CONST f = 5 + c; (* folding! *) CONST g = f – 11; (* folding! *)

VAR v : ARRAY g OF REAL;(* error, since dimension is negative *)

Type Aliases

TYPE t1 = REAL;

TYPE t2 = t1;

TYPE t3 = t2;

VAR x : t3;

VAR y : REAL;

Type Aliases

Type Aliases provide a way for users to define their own types – like C’s “ typedef ”

So, what needs to be done? We mainly need to store 2 things:

The name of the aliasThe base type it represents

Type Aliases

So, let’s look at this example more closely:TYPE t1 = REAL;

TYPE t2 = t1;TYPE t3 = t2;

VAR x : t3;VAR y : REAL;

In this case, “x” has a alias name of “t3”, and an underlying type of “REAL”. Notice we don’t need to remember the intermediate aliases!

So, How Do We Implement It?

Since type aliases are referred to by an identifier (their name), they will eventually need to get on the Symbol Table.

So, one way is to have some kind of STO for Type Aliases TypeAliasSTO Since it extends your base STO, it will have the

Name and Type fields you need to store your information.

Putting it on the Symbol Table

This method (using TypeAliasSTO) fits nicely into the given code, relying on the SymbolTable and STO hierarchy:

void DoTypeDecl (String id, Type baseType) { if (m_symtab.access (id) != null) { m_nNumErrors++; m_errors.print (Formatter.toString(ErrorMsg.redeclared_id, id)); } TypeAliasSTO sto = new TypeAliasSTO (id, baseType); m_symtab.insert (sto); }

Type Aliases

There are other ways to handle Type Aliases, such as making an AliasType in your Type hierarchy or overloading the access method of the symbol table to handle Type as well as STO.

Think about what you are most comfortable implementing and what can be done to make your program work before the deadline.

More Type Checking

All basic types use structural equivalence

Arrays and Records use strict name equivalence

Pointers depend on what they point to

Type aliases use loose name equivalence

Alias Equivalence

TYPE foo = INTEGER;TYPE bar = foo;TYPE baz = bar;VAR x : INTEGER;VAR y : baz;BEGIN x := 5; (* OK *) x := y; (* OK by loose name equivalence *) RETURN 0;END.

Alias/Record Equivalence

TYPE r1 = POINTER TO RECORD a, b : REAL;TYPE r2 = r1;VAR x : POINTER TO RECORD a, b : REAL;VAR y : r1;VAR z : r2;

x y? NOx z? NOy z? YES

Now, Procedures!

First, some fundamental differences from 131A:

We are writing a static translator, not an interpreter. Once we finish the function declaration, including the

body, we’re done. We don’t need to remember the code in the body, since we’ll just be spitting out assembly code (Project 2).

A procedure call will basically boil down to an assembly “call foo” type instruction, once all type checking is complete.

Procedures

For Project 1, we will need to: Check the procedure call against the procedure

declaration to ensure argument symmetry. Check the body of the procedure, type checking

the same way we check statements in main. Check the return logic of the procedure.

ProcSTO

In order to do most of these checks, we will need to store some information about the function. ProcSTO is designed for this!

Things that should be stored: The Return Type (currently only stores if there is

a return type, but not the actual type). All parameter information:

Total number of parametersType of each parameter, including whether VAR or

non-VAR

VAR vs. non-VAR

All parameters are VarSTOs, whether or not they have the keyword “VAR” in front of them.

In Oberon, the keyword “VAR” for a procedure parameter means that variable is a reference variable (instead of a value variable).

Think of passing by value versus passing by reference.

If everything was good and well in the world, the keyword “VAR” for parameters would’ve been “REF” instead.

Procedure Declaration

ProcDecl ::= T_PROCEDURE OptReceiver:_2 IdentDef:_3 {: ((OParser) parser).SaveLineNum (); ((OParser) parser).DoProcDecl_1 (_3, _2); :}

OptFormalParams T_SEMI DeclSeq OptStmts T_END T_ID:_9 {: ((OParser) parser).DoProcDecl (_3, _9); :} ;

Procedure Declaration

void DoProcDecl_1 (String id, STO stoReceiverVar) { if (m_symtab.access (id) != null) { m_nNumErrors++; m_errors.print (Formatter.toString(ErrorMsg.redeclared_id, id)); } ProcSTO sto = new ProcSTO (id); if (stoReceiverVar == null) { m_symtab.insert (sto); // Inserted into outer scope } m_symtab.openScope (); // New scope opened m_symtab.setProc (sto); // Current Proc we’re in is set if (stoReceiverVar != null) { m_symtab.insert (stoReceiverVar); } }

Procedure Declaration

void DoProcDecl (String strBeginID, String strEndID) {

if (!strBeginID.equals (strEndID)) {

m_nNumErrors++;

m_errors.print (Formatter.toString (ErrorMsg.improper_proc_end, strEndID));

}

m_symtab.closeScope (); // Close scope (pops top scope off)

m_symtab.setProc (null); // Says we’re back in “main”

}

Procedure Declaration

PROCEDURE foo (a, b : REAL; VAR c : REAL) : BOOLEAN;

VAR x : BOOLEAN; (* Local Variable *)

BEGIN

x := a > b;

x := x & c;

RETURN x;

END foo;

In this example, we want to create a ProcSTO with the name “foo”, set its return type to BOOLEAN, set its param count to 3, and remember the parameters are: non-VAR REAL, non-VAR REAL, and VAR REAL).

Furthermore, we want to insert the VarSTO for a, b, c, and x into the SymTable so they are available for the body of the procedure.

Procedure Call

Now that we have a ProcSTO in the SymTable, and type-checked the procedure declaration, we are ready to call it.

foo(1, 2, 3); Given the above call, there would be an error

since ‘3’ is not addressable and cannot be sent to a VAR (reference) parameter.

Procedure Call

So, when we call a procedure, we want to get the ProcSTO from the SymTable and check its parameters with the arguments.

Consider making a Vector of some new object (you create it how you want) that holds the parameters. When you call the function, compare the two vectors. Important design choices!!!

What to do Next!

1. Finish up Phase 2.

2. Write more test programs.

3. Start Phase 3.

4. Come to lab hours and ask questions.

Topics/Questions you may have

Anything else you would like me to go over now?

Anything in particular you would like to see next week?