1. CSE 131B – Compiler Construction II Discussion 1: Getting Started 1/10/2007

2. Introduction  Contact Info: Garo Bournoutian cs131f1@ieng9.ucsd.edu  Availability: I am available at my designated lab hour times (Tu 4-7 and Th 3-7), or by appointment. Feel free to e-mail me.

3. About Me  I was an undergraduate here and actually took this class back in Spring 2004. I know how much work this can be, but it is definitely doable – the end result is a very rewarding feeling.  This is my second year as a CSE graduate student, specializing in computer architecture based on neurological principles.  I also work at Qualcomm, utilizing many of the skills I learning from taking this class!  If you want to talk about things like grad school and industry, I would be more than happy to.

4. Overview  Format and purpose of our discussions  What’s new from 131A  Starter Code  What to do Next  Topics/Questions you may have

5. What’s new from 131A  In 131A, you built an Interpreter for XQuery Took some input as well as a source program, and provided the appropriate output  In 131B, we are building a Translator Takes the source code (oberon) and compiles it (translation) into the target code (assembly). Then input will be fed to the target program to provide the run-time output

6. Phases of Compilation  Lexical Analysis (Lexer.java) Covered in 131A; you probably won’t even touch this file  Syntax and Semantic Analysis (parser.cup) Project 1 will focus on the Semantic side of things. In other words, does some syntactically correct piece of code make sense.  Code Generation Project 2 will focus on this

7. Starter Code  The Starter Code is located in: /home/solaris/ieng9/cs131f/public/starterCode.tar  Look through the files and get familiar with each of them.  The file CUP_Overview in the Starter Code is also helpful

8. Important Files  oberon.cup Contains the Parser’s rules and actions (defines the grammar) Example: Designator2 ::= Designator2:_1 T_DOT T_ID:_3 {: RESULT = ((OParser) parser).DoDesignator2_Dot (_1, _3); :} | Designator2:_1 T_LBRACKET ExprList T_RBRACKET {: RESULT = ((OParser) parser).DoDesignator2_Array (_1); :} ;

9. Important Files  OParser.java Contains methods for semantic analysis. Example: STO DoDesignator2_Dot (STO sto, String strID) { if (sto.isVar()) { return (sto); } else { m_nNumErrors++; m_errors.print (Formatter.toString (ErrorMsg.not_variable, sto.getName())); return (new ErrorSTO (sto.getName ())); }

10. Important Files  SymbolTable.java Contains the functions that support Scopes. insert(STO), access(String), accessGlobal(String), accessLocal(String), openScope(), closeScope(), etc.

11. STO Hierarchy STO ProcSTOTypeAliasSTOExprSTOErrorSTO VarSTOConstSTO  You can change this around!  Look at the methods in each and how they are overloaded (i.e., isVar(), isConst())

12. Organization is your friend!  Don’t just try to throw code into the files.  Think about the current problem at hand.  Also think about upcoming tasks.  Try to make your code as general as possible.  Remember that in Project 2 we will be generating assembly code, so the more forethought that occurs in Project 1, the easier Project 2 will be!

13. Organization is your friend!  Keep the software engineering and design principles described during lecture in mind.  Avoid “Code Bloat” – rather than cut & pasting code, encapsulate that common code into another module. This will make debugging tremendously easier  Make sure you use some kind of revision control (e.g. svn) and regression testing, this way you can always go back to a working copy.

14. An Idea  Define a new function inside OParser to check expressions  Define Operator classes to assist type checking  Ex: In OParser: STO DoBinaryExpr(STO a, Operator o, STO b) { STO sto = o.checkOperands(a, b); if (sto.isError()) { … } return sto; }

15. An Idea  In each Operator class, we can do something like this:  STO checkOperands(STO a, STO b) { if (!a.isNumeric() || !b.isNumeric()) { // Error return (new ErrorSTO(…)); } else if (a.isInteger() && b.isInteger()) { // return INTEGER type STO } else // return REAL type STO }

16. An Idea  That was just an example of how good software engineering can make coding this project simple.  It may seem like extra overhead at first, but once it’s all in place, the compiler will almost write itself!  Again, that example is not the only way to do things, nor is it necessarily the best way.

17. What to do Next! 1.Find a partner and setup a Unix Group (requestgroup)! 2.Use tools like Subversion (or CVS) and Eclipse to make your life easier. 3.Understand the Starter Code. Look through all the files! 4.Implement a basic type structure (Type.java – more details next week). 5.Attempt Checks 1 - 4. 6.Come to lab hours and ask questions (We’re here for you!) 7.Check the Webboard – Often people have the same question as you and it may already have been answered.

18. 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?  Administrative issues (accounts/groups/etc)?  Deep thoughts?