[ Norsk ] [ English ]
[an error occurred while processing this directive] : Project


Prosjekt del II: Semantikkanalysator

Me held fram me å oppdatera sida, men de bør snøggast råd taka fatt på oppgåva. Me vil kringkasta alle endringar på postlista mailto:i125@ii.uib.no. Om du ikkje er meld på lista, send ei melding til mailto:i125-request@ii.uib.no med teksta «subscribe».

Mål

De skal laga ein syntaks og semantikkanalysator (parser) som kjenner igjen gyldige program i C-, ser om programmet er type-korrekte og gjev syntakstreet og symboltabellen for programmet. Om programmet ikkje er korrekt, skal analysatoren melda feil.

De skal løysa oppgåva i grupper på to personar. (Om talet ikkje går opp, skal de spyrja oss. Me godtek éi og berre éi gruppe på tre.)

Frist

Siste frist for innlevering er fredag 26. oktober 2001 kl. 10:15. Ein kan levera til førelesar Jean Blair på førelesinga, eller på førehand til gruppeleiar Ole Kåre Endresen.

Innhald

Innleveringa skal innehalda:

  • Utskrift av kildekoden.
  • Utskrift av dokumentasjon.
  • Stig til ein katalog på undervisingsanlegget der me kan finna alle dei køyrbare klassene med treng for å testa programmet.

Programmet

Programmet skal lesa kildekode til eit program i C- frå standardinn og skriva det abstrakte syntakstreet og symboltabellen til standardut etter at programmet er slutt. Om programmet finn feil i kildekoden, skal feila meldast til stderr. Me har nokre døme på korleis utdata kan sjå ut (sjå nedanfor).

Feilrapportering
  • Når analysatoren finn feil under syntaksanalysen, skal han som best han kan finna ut kva slags feil det er tale om, og kvifor han oppstod.
  • Kvar feil skal meldast med ein referanse til linenummer og helst kolonnenummer i kildefila.
  • Analysatoren skal freista å redda seg inn etter feil.

Me krev at analysatoren held fram me lesinga etter somme feil:

  • Feil i uttrykk. Ved t.d.
         if ( a <= b <= c ) {
           foobar ( a + b ) ;
         }
       
    skal programmet rapportere feil i føresetnaden, og halda fram for å analysera satsane i vilkårsblokken.
  • Multiple deklarasjonar. Om du skriv
         int foobar ;
         void foobar ( int b ) { ... } ;
       
    i same blokken, skal programmet seia at foobar er definert to gonger, men halda fram. Kvar multippel deklarasjon bør ikkje gjeva meir enn ei feilmelding, so om du nyttar foobar både som variabel og funksjon i programmet, so skal det likevel ikkje rapportera fleire feil. error.
Symboltabell
  • Alle symboler i programmet skal rapporteres etter analyse, ikke bare dem som er gyldig på toppnivå.
  • For hvert symbol skal der rapporteres navn og type.
  • Husk at parametre til funksjoner regnes som lokale variabler.

I den neste innleveringa skal funksjonar og lokale variablar få fleire attributtar enn dei me nyttar her. Dette kan det vera lurt å ta høgd for, allereie no.

For å handtera lokale variablar, kan de nytta ein stabel med symboltabellar. Når de kjem til ein samansett setning, legg de ein ny tabell øvst i stabelen, og når de kjem til slutten av ei slik setning, går det eit hakk nedover i stabelen. Kvar node i syntakstreet kan halda ein referanse til den tabellstabelen som er gyldig i denne noden. For å skriva ut symboltabellen, kan ein gå gjennom treet og skriva ut den øvste tabellen i kvar node der eit gildskapsområde.

Typesjekk
  • Alle variablar og funksjonar må vere deklarerte før bruk.
  • Funksjonskall må ha riktig tal på parametrar, og parametrane må vera av riktig type.
  • Tildeling må vera av kompatible typer (i praksis bare heltall).
  • Programmet skal ha ein main-funksjon som ikkje tek parametrar og som returnerar int.

Eksempel

Eit fyrste døme med syntakstre.

Fibonacci

To program for utrekning av fibonaccital:

  1. #nor# Rekursivt: #eng# Recursive: fibrec.c-
  2. #nor# Med tabellar: #eng# With arrays: fibarr.c-

Dokumentasjon

  • Beskriv oppbyggingen til programmet.
  • Legg vekt på de delene som krevde spesiell behandling eller hvor dere måtte foreta avveininger.
  • Oppsummer enkel og gjentakende kode istedenfor å ta med den samme biten om og om igjen.
  • Ikke ta med generell tekst om program-analyse, men begrens dere til deres egen kode.
  • Hold dokumentasjonen kort. Det skal være lettere å lese dokumentasjonen enn å lese koden.
  • Dersom dere bruker flere klasser, skal dere beskrive hvilken rolle klassene har og hvordan de samarbeider.
  • Dere kan bruke UML til å beskrive deler av systemet hvis dere har lyst til det.
  • Lag et gjennomgangseksempel hvor dere beskriver hvordan analyse og typesjekking konkret foregår på et enkelt eksempel (gjerne med typefeil!). Legg ved kildekoden for klassene som er brukt i dette eksempelet. (Hvis dere planlegger eksempelet på forhånd vil dette også hjelpe dere med å utforme koden).
  • Gjennomgangseksempelet kan gjerne brukes til å illustrere beskrivelsen av oppbyggingen.
  • Lag utskrift av en kjøring for gjennomgangseksempelet deres. Dere kan bruke kommandoen script for å lage dette. (Dokumentasjon for denne finner dere med man script.) Lag gjerne flere kjøreeksempler.

Tips

  • Tak dei enkle tinga først og utvid programmet etter kvart.
  • Skriv dokumentasjon medan de skriv koden. Etterpå vil alt de har gjort verka trivielt (får me håpa), om de kan hugsa tilbake då.
  • Start tidleg med oppgaven. Ting tek tid.
  • Ikkje vent til emnet er teke opp på førelesing. Då vil de berre koma på etterskudd og sjelden verta ferdige i tide.
  • Det er ikkje éin riktig måte å gjera oppgåva på.
  • Diskutér oppgåva med andre i gruppa eller på nyhendegruppa.