Obligatorisk oppgave 2 i INF5110 v?ren 2007

Merk: Dette er en tidlig utgave. Det kan komme presiseringer.

Dette er den andre av to oppgaver v?ren 2007. Den bygger videre p? det som er gjort i oblig 1.

Innhold

• Hensikten med oppgaven
• Selve oppgaven
• Frist
• Testsuite
• Gjennomf?ring og levering
  • Levering

Hensikten med oppgaven

Tanken bak denne oppgaven er at man skal f? enn? mer praktisk erfaring med hva som gj?res i en kompilator, nemlig:

• Analyse av et programs statiske semantikk.
• Anvendelse av et abstrakt syntakstree.
• Typesjekking, sjekking av bruk av navn og blokkstrtuktur i spr?k.

Oppgaven

Del to av den obligatoriske oppgaven bygger p? den f?rste delen, og g?r ut p? ? implementere kravene til statisk semantikk, beskrevet i spr?knotatet. Det holder med ? levere inn ?n parser. I tillegg skal resultatene fra kj?ring av en testsuite leveres.

• Ta utgangspunkt i et abstrakt syntakstre og sjekke om treet oppfyller alle kravene gitt av spr?kets semantikk.
• Gj?re om p? det treet som ble laget i oblig 1 om n?dvendig og lage en oversiktlig kode som benytter abstrakte klasser og funksjoner.
• Dersom man finner feil, gi en kort melding, som skrives ut p? skjermen.
• Returnere en verdi fra kompilatoren som forteller om koden var godkjent (0), om det var syntaksfeil (1) eller om det var semantikkfeil (2).

Frist

Fristen er fredag 11. mai. Fristen er endelig.

Testsuite

Det er laget en patch til det prosjktet som ble delt ut og som dere har bygd p? i oblig 1. Den ligger her og best?r av f?lgende.

• En ny Compiler-klasse (.\src\compiler\Compiler.java). Den inneholder et skall som brukes av testen. Den forutsetter at metoden compile() returnere en int 0, 1, eller 2, som forklart ovenfor.
• En hjelpeklasse til testen (.\src\test\FileEndingFilter.java).
• Klassen som utf?rer testen (.\src\test\Tester.java).
• Noen linjer som kan legges til build-filen for ? kalle testen. (./build.xml.patch).
• En katalog med filer det testes mot (./tests/). Filene med navn som inneholder fail skal gi semantikkfeil (2). Ingen av filene skal gi syntaksfeil (1).

Plass?r filene slik katalognavnene er angitt her relativt til banen til prosjektet deres (Pass p? ? legge til innholdet i Compiler.java og build.xml uten ? skrive over de klassene dere har!).

Etter det kan testen kj?res med ant test.

Klassen Tester kaller opp klassen Compiler for alle testene i katalogen ./tests/. Det skrives ut ?n linje pr test og en oppsummering.

Sjekkliste for del to

Under f?lger en sjekkliste for semantikken (merk at det kan v?re flere krav, les ogs? spr?knotatet) i D#:

• Multiple deklarasjoner av ett navn i samme skop m? detekteres.
• Typekonvertering: int is-a float, int kan forfremmes til float i aritmetiske uttrykk, returverdier, og som aktuelt argumentuttrykk i funksjonskall.
• Main-funksjonen
  1. Funksjonsdeklarasjonen til Main, m? finnes p? ?verste blokkniv? av programmet.
  2. Signaturen m? matche void Main(), d.v.s. ingen argumenter og ingen returverdi.
• Funksjonsdeklarasjoners returverdi er:
  • void, eller
  • type i symboltabellen (predefinert eller brukerdefinert struct)
• Stmts
  • AssignStmt
    1. Variabelen p? venstresiden m? v?re deklarert.
    2. Typene p? vs. og hs. m? v?re like, etter evt. typekonvertering.
  • ReturnStmt
    1. Forekommer bare i en funksjonsblokk (en FuncDecls liste av Stmts), ikke i de anonyme blokkene til IfStmts og WhileStmts.
    2. Typen til uttrykket stemmer overens med funksjonens deklarerte type. Merk ogs? s?rtilfelle med void returverdi, da blir argumenter til return-setningen en feil.
  • WhileStmt: m? ha en betingelse av typen bool.
  • IfStmt: m? ha en betingelse av typen bool.
• Exps
  • NewExp: argumentet m? v?re deklarert som en struct-type.
  • Literals: M? v?re av en de forh?ndsdefinerte typene i spr?ket: float, int, string, bool eller null.
  • Bin?re uttrykk (felles for alle operatorene bortsett fra negasjon) m? ha samme typer, etter evt. typeforfremming, p? begge sider av operatoren.
  • Aritmetiske uttrykk: som for bin?re uttrykk, men typene m? ogs? begrenses til aritmetiske (int eller float).
  • Logiske uttrykk (med "&&", "||" eller "!"): begge operander m? v?re av typen bool.
  • CallStmt
    1. Navnet som kalles m? v?re deklarert som funksjon.
    2. Kallet m? ha samme antall aktualparametre som formalparametre.
    3. Aktualparametrene m? ha samme type (eller mulig ? tilordne) som formalparametrene.
    4. Bruk av referanser ("ref") m? stemme overens med funksjondeklarasjonen.
  • Var
    1. Evt. strukt-type m? v?re deklarert.
    2. Navnet m? v?re deklarert.

Gjennomf?ring og levering

Man leverer sammen med den samme gruppen som man leverte oblig 1. Det som skal leveres er:

• En forside med navn og brukernavn fra dem som leverer besvarelsen.
• En kort rapport om gjennomf?ringen med forklaring av designet.
• All kode som trengs for ? bygge og kj?re parserne, herunder:
  • JFlex-koden for skanneren
  • CUP-koden for en av syntaksvariantene
  • Java-koden for syntakstreet og semantikksjekking
  • Byggeskript: build.xml eller Makefile
• Instruksjoner for bygging og kj?ring
• Utskrift fra kj?ring med testesuiten.

Levering

Besvarelsen leveres som ett pakket filarkiv (zip- eller tgz-format) til gruppel?rer Fredrik S?rensen <fredrso@ifi.uio.no>.

Subversion-brukere kan ogs? levere via et repository (bare gi meg leseaksess, og kommandoen for ? lese ut prosjektet). Rapporten skal ved bruk av SVN enten sendes p? epost, eller ligge p? "roten" (/) i repositoriet.