Introduction to Compiler Construction II: Getting Started with CSE 131B

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 • You can change this around! • Look at the methods in each and how they are overloaded (i.e., isVar(), isConst()) STO ProcSTO TypeAliasSTO ExprSTO ErrorSTO VarSTO ConstSTO

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! • Find a partner and setup a Unix Group (requestgroup)! • Use tools like Subversion (or CVS) and Eclipse to make your life easier. • Understand the Starter Code. Look through all the files! • Implement a basic type structure (Type.java – more details next week). • Attempt Checks 1 - 4. • Come to lab hours and ask questions (We’re here for you!) • 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?