DOC PREVIEW
Columbia COMS W4115 - Getting It Right

This preview shows page 1 out of 3 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 3 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 3 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Getting It RightCOMS W4115Prof. Stephen A. EdwardsSpring 2003Columbia UniversityDepartment of Computer ScienceGetting It RightYour compiler is a large software system developed byfour people.How do you get it right?Subjects•Team-oriented development•Interface-oriented design•Version control systems•assert()•Regression test suites•Writing tests•Code coverage•MakefilesTeam-oriented DevelopmentBasic challenge: Remove as many inter-persondependencies as possible.One group asked if the lexer/parser person should finishbefore the tree walker person started.Divide and conquer: try to make it so that each personcan work at his/her own rate and not depend on others.Tricky: each pass depends on the previous one.Solution: careful design and modularityInterface-oriented DevelopmentDivide your compiler into a series of modules, e.g.,1. Lexer/Parser2. Static semantics3. Code generation4. AssemblerClearly define the interface between each module.You’ll want to write this in your project report, anyway.Make the interfaces the “contracts” between the teammembers.Interface-oriented designWrite the interfaces first.Document them well.Write the public class definition, the method declarations,and the comments first.Later, fill in code for each method, private fields, etc.Use javadoc to extract documentation from your Javacode and share with other group membersVersion Control SystemsFour people working on a single program is not as easyas just one.Need some way to make sure everybody’s working on thesame program.Version control systems a good solution.The CVS Version Control SystemBasic model:Repository:Grammar.g,vMain.java,vMakefile,vAlice’sworkingdirectory:Grammar.gParser.javaLexer.javaMain.javaMain.classMakefileBob’sworkingdirectory:Grammar.gMain.javaMain.classMakefileUsing the CVS Version ControlSystem1. Prepare a repository2. Add an empty sudirectory to the repository3. Create a working directory4. Add files, update directory, commit changesOne group member does 1,2 once.Each group member does 3 once.Each group member does 4 repeatedly.Using CVSCreating a working directory:%mkdir mydir% cd mydir% cvs checkout ourprojEditing, adding, and updating%cd ourprojedit files, compile, etc.% cvs add Grammar.g% cvs commit Grammar.g% cvs updateAssertclass Foo {public static void main(String[] args) {assert false;}}% javac -source 1.4 foo.java% java -ea FooException in thread "main"java.lang.AssertionErrorat Foo.main(foo.java:3)Assert Philosophy•Catch errors early and often•Check function arguments are acceptableE.g., assert n != null;•Check function return value is consistent•Check constructor has filled in every field•Check object state is consistent•Check loop invariants•For the really ambitious, write methods that checkconsistency of a whole data structure.Regression test suitesHow to avoid introducing new bugs when adding features?Partial answer: build something that tells you whetheryou’ve broken the program.Regression suite:•collection of tests•exercises as much of your program as possible•results are compared with “golden” referencesRegression testsEasiest is when program takes a text file as input andproduces text as output.Fortunately, compilers behave like this.Regression test inputs: short programsRegression test golden references: assembly languageExample testsmodule test_emit1:type a;type b;input a;input b : integer;output c : integer;emit a;emit b;emit cend modulemodule test_emit2:output a;output b : integer;output c : float;emit a;emit b(10);emit c(5.0f)end moduleWriting TestsTry to cover as much of your language as possible.Try to write one test for each feature mentioned in thelanguage reference manual.Build sequences of tests that start with simple versions ofa feature and build into the most complex.Keep tests focused: easier to track down fault if one fails.Running TestsEasiest is to use a scripting language that•invokes the test,•compares the outputs, and•logs results and any errorsFor CEC, I wrote a shell script to do this.Shell ScriptCarefully runs two programs.Compares output to reference file.Stores results when it differs.#!/bin/shSTRLXML=./strlxmlXMLSTRL=./xmlstrlgloballog=teststrlxml.logrm -f $globallogerror=0Shell ScriptCheck() {basename=‘echo $1 | sed ’s/.*\\///s/.strl//’‘reffile=‘echo $1 | sed ’s/.strl$/.out/’‘xmlfile=${basename}.xmloutfile=${basename}.outdifffile=${basename}.diffecho -n "Parsing $basename..."echo "Parsing $basename" 1>&2$STRLXML < $1 > $xmlfile 2>&1 || {echo "FAILED: strlxml terminated"error=1 ; return 1}$XMLSTRL < $xmlfile > $outfile 2>&1 || {echo "FAILED: xmlstrl terminated"error=1 ; return 1}Shell Scriptdiff -b $reffile $outfile > $difffile 2>&1 || {echo "FAILED: output mismatch"error=1 ; return 1}rm $xmlfile $outfile $difffileecho OK}for file in tests/test*.strldoCheck $file 2>> $globallogdoneexit $errorCode coverageBasic idea: your test suite should at least send theprogram counter over every part of your code.To measure coverage, need some sort of tool that can tellwhen each line of code is executed.I found a couple of them:•gcov: works with gcc to report for C (C++?)•clover: Commercial tool for Java, but free for studentsand open-source developersThere are many more.Example of gcov$ gcc -fprofile-arcs -ftest-coverage tmp.c$ a.out$ gcov tmp.c87.50% of 8 source lines executed in file tmp.cCreating tmp.c.gcov.main() {1 int i, total;1 total = 0;11 for (i = 0; i < 10; i++)10 total += i;1 if (total != 45)###### printf ("Failure\n");else1 printf ("Success\n");1 }MakefilesHow do you make it easy to compile your compiler?Need to run ANTLR to generate files, then run javac onthe results.How do you make sure everything gets compiled whenneeded?A Basic Makefile% cat MakefileSimp.class : Simp.javajavac Simp.java%make Simp.classjavac Simp.java%make Simp.classmake: ‘Simp.class’ is up to date.%A More Complicated MakefileJAVASRC = SimpParser.java SimpWalker.java \SimpLexer.java SimpParserTokenTypes.javaSimpParser.class : $(JAVASRC)javac $(JAVASRC)SimpParser.java SimpLexer.java : Simp.gjava antlr.Tool Simp.gclean :rm -f *.class SimpParserTokenTypes.txt \SimpParser.java SimpWalker.java \SimpLexer.java \SimpParserTokenTypes.javaA More Complicated Makefile% makejava antlr.Tool Simp.gANTLR Parser Generator Version 2.7.1 1989-2000 jGuru.comjavac SimpParser.java SimpWalker.java SimpLexer.java SimpParserTokenTypes.java%rm SimpParser.class% makejavac SimpParser.java


View Full Document

Columbia COMS W4115 - Getting It Right

Documents in this Course
YOLT

YOLT

13 pages

Lattakia

Lattakia

15 pages

EasyQL

EasyQL

14 pages

Photogram

Photogram

163 pages

Espresso

Espresso

27 pages

NumLang

NumLang

6 pages

EMPATH

EMPATH

14 pages

La Mesa

La Mesa

9 pages

JTemplate

JTemplate

238 pages

MATVEC

MATVEC

4 pages

TONEDEF

TONEDEF

14 pages

SASSi

SASSi

16 pages

JTemplate

JTemplate

39 pages

BATS

BATS

10 pages

Synapse

Synapse

11 pages

c.def

c.def

116 pages

TweaXML

TweaXML

108 pages

Load more
Download Getting It Right
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Getting It Right and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Getting It Right 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?