Eksamen i : Med Svarforslag UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet INF5110 - Kompilatorteknikk Eksamensdag : Onsdag 3. juni 2009 Tid for eksamen : 14.30-17.30 Oppgavesettet er på : Vedlegg : Tillatte hjelpemidler : 5 sider (pluss vedlegg) 3 sider (side 6, 7 og 8, rives ut, fylles ut og leveres) Alle trykte og skrevne Les gjennom hele oppgavesettet før du begynner å løse den første oppgaven. Dersom du savner Sopplysninger i oppgaven, kan du selv legge dine egne forutsetninger til grunn og gjøre rimelige antagelser, så lenge de ikke bryter med oppgavens "ånd". Gjør i så tilfelle rede for disse forutsetningene og antagelsene. Deler av oppgavene 2 og 3 besvares ved bruk av vedlegg. Oppgave 1 (30%) Gitt følgende grammatikk, som opplagt er flertydig ( ambiguous ): S S S a Her er S startsymbol og eneste ikke-terminal, mens og a (og $) er terminalsymboler. 1.a Tegn LR(0)-DFA-en til grammatikken (etter standard utvidelse med S S), og nummerér tilstandene Svar 1.a: 1 4 S S S ->.S S -> S. S -> S.S S -> S S. S ->.S S S -> S. S S ->.S S S ->S. S S ->.a S ->.a a 5 S -> a. a 1.b Beregn First- og Follow-mengdene til S og S (det holder å oppgi dem). Angi så hvilke LR(0)-tilstander som får løst og som ikke får løst sine konflikter ved hjelp av SLR(1)- betrakninger. Forklar. 1
Svar 1.b: First Follow S a $ S a $ I tilstand 1 er bare skift mulig (med a), altså ingen konflikt. I tilstand 2 er det ut fra LR(0)-betrakninger en skift/reduser-konflikt, men den løser seg med SLR(1)-betrakninger siden Follow(S ) ikke inneholder. I tilstand 3 er bare skift mulig (med a), altså ingen konflikt I tilstand 4 er det med LR(0)-betrakninger en skift/reduser-konflikt, og den løser seg ikke med SLR(1)-betrakninger siden Follow(S) inneholder. 1.c Vis hvordan du, for hver av kravene 1.c.1 og 1.c.2 under, vil velge løsning på konfliktene i de LR(0)-tilstander som ikke fikk løst sine konflikter i 1.b. 1.c.1: Setninger i språket skal tolkes venstre-assosiativt 1.c.2: Setninger i språket skal tolkes høyre-assosiativt Svar 1.c: Det var altså bare tilstand 4 som ikke fikk løst sin konflikt i 1.b. Vi løser det da slik: 1.c.1: Vi reduserer med: S -> S S 1.c.2: Vi skifter for input til tilstand 3. Andre symboler er ulovlig. 1.d Gitt følgende litt mer kompliserte grammatikk (hvor * er et nytt terminalsymbol): S S S * S a Denne er også opplagt flertydig. Lag en grammatikk som er entydig, som beskriver samme språk, og der er høyre-assosiativ og * har høyere presedens enn. Svar 1.d: S -> T S T T -> * T a 1.e Avgjør om følgende grammatikk er en LR(1)-grammatikk. Forklar. A B x y D x B d e D e Her er A startsymbol, A, B og D ikke-terminaler og d, e, x, y terminalsymboler. 2
Svar 1.d: A ->.A $ A ->.B x y $ A ->.D x $ B ->.d x B ->.e x D ->.e x A B D d e A -> A. $ B -> e. x D -> e. x Start-tilstanden i LR(1)-DFAen blir som angitt til venstre over. Ut fra den kan man jo få mistanke om at e-kanten må føre til noe rart. Og i den tilstanden den fører til ser vi altså at den er en redusér/resusér-konflikt, der det ikke hjelper å se på neste input. Om det er en x vet man jo like lite (og er det noe annet er det feil). Altså ikke LR(1). Man kan også forsøke å argumentere direkte fra grammatikken. Om setningen starter med en e, så ser vi at neste input-symbolet må være en x. Om det etter det kommer en y, vil første e en skulle reduseres til en B, om det kommer $ skal den reduseres til en D. Men siden vi i LR(1) bare får lov å se ett symbol framover (altså på x en) er det ikke mulig å skille mellom disse. Altså, ikke LR(1). Merk at hintet gir en klar indikasjon på at grammatikken ikke er LR(1). For å vise at den er det måtte man nemlig ha sett på alle tilstandene. Oppgave 2 (20%) 2.a Noen har fått den idé å lage et språk hvor klasser kan ha noe tilsvarende by-value-result - parametere. Klasser har ingen konstruktører, og by-value-result parametere spesifiseres som en del av en klassedefinisjon (val-res int v). Parametrene kan brukes innen klassen som om de var vanlige variable. De aktuelle parametrene må være variable av riktig type, og ved generering av et objekt av klassen overføres adressene til disse variablene. Til forskjell fra callby-result for funksjoner blir verdiene ikke returnert når et objekt er generert. For å få verdiene returnert må man kalle en predefinert metode return, som alle klasser har og som man derfor ikke trenger å erklære. Man kan således returnere verdier flere ganger, ved gjentatte kall på return, men vi skal dog ikke bruke dette i det følgende. Det følgende er et program i dette språket. 3
{ class A (val-res int v) { void m(){v = v + 1; ; A ra; B rb; C rc; class B { int x = 1; void f() { ra = new A(x); ra.m(); ; class C { int z = 1; void f() { int z = 3; ra = new A(z); ra.m(); ; void main() { rb = new B(); rb.f(); rb.return(); // 1 rc = new C(); rc.f(); rc.return(); // 2 Tegn stakkene som de ser ut når aktiveringsblokken for m er på toppen av stakken for både //1 og //2, dvs på det tidspunkt hvor den ene setning i m er utført men før exit av m. Antyd hvordan du ville implementere by-value-result parametre for klasser ved også å tegne inn objektene av klassene A, B og C. Språket er statisk skopet. Besvar spørsmålet ved å gjøre figurene på side 6 ferdige, dvs skissér hvordan parameteren v representeres, og fyll inn manglende verdier og linker i figurene. Svar 2.a //1 4
//2 2.b Designeren av språket i 2.a vil gjerne bruke stakk-organisering av metodekall. I hvilket av tilfellene //1 og //2 går dette galt, og hvorfor? Som en del av svaret kan du eventuelt tegne stakkene som de ser ut når return er på toppen av stakken. Svar 2.b I //2 overføres addressen til variablen z, som er en del av aktiveringsblokken for kallet på rc.f og som derfor ikke er der når metoden rc.return kalles. //2 5
Oppgave 3 (30%) 3.a Det følgende er en del av grammatikken for et språk med klasser. class class id signatures class class id signatures bodies class class id class-heading signatures class class id class-heading signatures bodies class-heading extends implements extends implements ε extends extends id implements implements id Ord i kursiv er ikke-terminaler, ord og tegn i fet skrift er terminal-symboler. id representerer et navn. Språket er spesielt på den måten at selv om det bare finnes klasser, så defineres interfacer som klasser, der det ikke er implementasjoner av noen av metodene. Av denne grunn er definisjonen av en metode delt opp i en signatur (navn, type, og parametere) og i en body. Tilsvarende er en klasse definert ved et sett med signaturer og eventuelt ved et sett av bodies. En klasse som bare inneholder et sett av signaturer er altså en interface. En klasse med bodies må ha implementasjoner av alle metoder. I en klasse kan man i tillegg til metoder (ved signaturer eller ved signaturer samt bodies) også spesifisere (ved en class-heading) at klassen extender en annen klasse og/eller implementerer en annen klasse. Det er to regler i dette språket: 1. I en klasse kan det etter extends bare følge et klasse-navn, og etter implements bare følge et interface-navn 2. I en interface kan det etter extends bare følge et interface-navn, og det skal ikke være noen implemets-del Fyll ut de tomme felter (markert med *) i attributtgrammatikken på side 7 slik at attributtet ok for class er true hvis en klassedefinisjon er gjort ifølge disse regler, ellers false. Det skal ikke testes om en klasse faktisk har implementasjon av alle metoder i signatures. Du kan anta at det finnes en insert (id, kind) som legger inn navnet id med egenskapen kind i symboltabellen. Du kan også anta at at lookup-kind(id.name)leverer den kind, som er lagt inn ved hjelp av insert. 6
Svar 3.a Grammar Rule class class id class-heading signatures class class id class-heading signatures bodies class class id signatures class class id signatures bodies class-heading ε Semantic Rule insert(id, interface) class-heading.kind=interface class.ok = class-heading.ok insert(id, class) class-heading.kind=class class.ok = class-heading.ok insert(id, interface) class.ok = true insert(id, class) class.ok = true class-heading.ok = true class-heading extends class-heading.ok = if class-heading.kind = class then extends.kind = class else if class-heading.kind = interface then extends.kind = interface class-heading implements class-heading.ok = if class-heading.kind = class then implements.kind = interface else if class-heading.kind = interface then false class-heading extends implements extends extends id implements implements id class-heading.ok = if class-heading.kind = class then extends.kind = class and implements.kind = interface else if class-heading.kind = interface then false extends.kind = lookup(id.name) implements.kind = lookup(id.name) 3.b I denne del av oppgaven skal vi se på implementasjonen av interfacer i dette språket. Det finnes ikke virtuelle metoder, så extends mellom klasser betyr bare at man arver egenskaper i form av variable og metoder (dvs deres implementasjon), mens extends mellom interfacer betyr at man arver metodesignaturer. En interface som arver en metode m og selv definerer en metode m vil ha bare én metode m. Referanser kan bare types med interfacer. Den vanlige reglen gjelder: at en referanse typet med en interface I både kan referere objekter av klasser som implementerer I og som implementerer interfacer som extender I, og selvfølgelig objekter av subklasser av slike klasser. Det gjelder følgende regler: 7
1. En klasse som implementerer en interface må ha implementasjoner av alle metodene i interfacet, enten ved at implementasjonene er gitt i klassen selv eller arvet fra en superklasse. 2. For en gitt metode m definert i en interface I gjelder følgende for kall (ri.m()) via en referanse ri typet med I: Hvis ri refererer et objekt av en klasse K som implements I, da kalles den metoden m, som er implementert i K, og denne må ifølge første regel finnes. Hvis ri refererer et objekt av en subklasse subk av K som også har en egen implementasjon av m, da kalles subk::m (dvs m definert i subk) bare hvis subk implements en interface subi, som extends I og som selv har metoden m (altså ikke bare har arvet den), ellers kalles K::m. Her skal subklasse (og extends for interfacer) forståes slik at den kan være i ett eller flere steg, mens implements altså nødvendigvis bare er i ett steg. Det følgende eksempel definerer 3 interfacer og 3 klasser. Hver klasse implementerer de metoder, som de ifølge den implementerte interface skal implementere (antydet med {...). { class I1 { void m1(); void m2(); class I2 extends I1 { void m2(); void m3(); class I3 extends I2 { void m3() ; I1 ri1; I2 ri2; I3 ri3; class A implements I1{ void m1() {...; void m2() {...; class B implements I2 extends A { void m1() {...; void m2() {...; void m3() {...; class C implements I3 extends B { void m3() {...; Det foreslås å implementere interfacer på en liknende måte som virtuelle, nemlig med en interface method table (imt) for hver for hver klasse som implementerer et interface. Tabellen for en interface som extender en annen interface vil på liknende måte som for virtuelle ha innganger 8
for metodene definert i superinterfacen. I en tabell er det en inngang for hver metode som finnes i det interface, som klassen implementerer, inklusive de metoder, som stammer fra superinterfacer. Tabellene er ikke som for virtuelle indeksert med et tall, men med selve metodenavnet (inklusive eventuelle parameter-typer). I praksis ville dette bli gjort ved hashing, men dette ser vi bort fra her. Hvordan ser disse tabeller ut for eksemplet over? Fyll inn de tomme boksene i figuren på side 8, i samme stil som de som er ferdigfylt. Svar 3.b 3.c Hvordan ville disse tabeller se ut hvis det i eksemplet i 3.b ikke er extends mellom interfacerne (men mellom klassene), og/eller vil det være feil? 9
Svar 3.c 3.d Hvordan ville disse tabeller se ut hvis det i eksemplet i 3.b ikke er extends mellom klassene men mellom interfacene, og/eller vil det være feil? Svar 3.d Det går greit å lage tabellen for klassene A og B, men for C bør kompilatoren gi melding om at klassen C ikke har noe implementasjon av m1 og m2. 10
Oppgave 4 (20%) Gitt følgende sekvens av treadresse-instruksjoner (TA-instruksjoner): 1 a = input 2 b = input 3 t1 = a + b 4 t2 = a * 2 5 c = t1 + t2 6 if a < c goto 8 7 t2 = a + b 8 b = 25 9 c = b + c 10 d = a b 11 if t2 = 0 goto 17 12 d = a + b 13 t1 = b c 14 c = d t1 15 if c < d goto 3 16 c = a + b 17 output c 18 output d 4.a Angi (som en sortert liste av tall) ved hvilke linje-numre det starter en ny basal blokk ( basic block ). 4.b Gi hver basal blokk nedover i programmet navn B1, B2, osv, og tegn opp flytgrafen (uten koden, men bare med navnet inni hver node). 11
Svar 4.a og 4.b: Svaret på 1.a er: 1, 3, 7, 8, 12, 16, 17, altså en slik inndeling: -------------------------------- 1 a = input B1 2 b = input -------------------------------- 3 t1 = a + b B2 4 t2 = a * 2 5 c = t1 + t2 6 if a < c goto 8 -------------------------------- 7 t2 = a + b B3 -------------------------------- 8 b = 25 B4 9 c = b + c 10 d = a b 11 if t2 = 0 goto 17 --------------------------------- 12 d = a + b B5 13 t1 = b c 14 c = d t1 15 if c < d goto 3 --------------------------------- 16 c = a + b B6 --------------------------------- 17 output c B7 18 output d B1 B2 B3 B4 B5 B6 B7 4.c Den som produserer TA-kode påstår at den er slik at temporære variable alltid er døde på slutten av hver basal blokk, og ved starten av programmet, selv om de samme temporærvariable altså blir brukt i flere basale blokker, slik som over. Formuler en generell regel som skal brukes lokalt på alle basale blokker for å sjekke om det produsenten av TA-kode sier er riktig, for et gitt TA-program. Vi antar her at alle variable er døde når programmet over stopper (etter siste instruksjon). Svar 4.c: Reglen kan være: For alle temporærvariable som blir avlest (i boka: used ) i den basale blokken, så må de bli gitt en verdi (i boka: be defined ) før de blir avlest. Man kunne alternativt si: Ingen temporærvariable må ha noen neste bruk (i boka: next use ) ved starten av den basale blokken. 4.d Bruk reglen du fant under 4.c til å undersøke hvordan dette forholder seg i den TA-koden som er angitt over. De temporære variablene heter t1, t2. Svar 4.d Det er én blokk der denne reglen ikke følges, nemlig i B4. Der brukes t2 i linje 11 uten å ha fått verdi først. Slutt på oppgavesettet Lykke til! 12
Stein Krogdahl og Birger Møller-Pedersen 13
Vedlegg til besvarelse av Oppgave 2 Kandidat nr:... Dato:... 2a //1 //2 14
Vedlegg til besvarelse av Oppgave 3 Kandidat nr:... 3a Dato:... Grammar Rule class class id class-heading signatures Semantic Rule insert(id, interface) * class.ok = class-heading.ok class class id class-heading signatures bodies insert(id, class) * class.ok = class-heading.ok class class id signatures class class id signatures bodies class-heading ε insert(id, interface) class.ok = true insert(id, class) class.ok = true class-heading.ok = true class-heading extends class-heading.ok = * class-heading implements class-heading.ok = * class-heading extends implements class-heading.ok = * extends extends id * implements implements id * 15
Vedlegg til besvarelse av Oppgave 3 Kandidat nr:... 3b Dato:... 3c 16