UNIVERSITETET I OSLO

Transkript

1 UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i : INF5110 Eksamensdag : Torsdag 9. juni 2005 Tid for eksamen : Oppgavesettet er på : 5 sider Vedlegg : intet Tillatte hjelpemidler : Alle trykte og skrevne Les gjennom hele oppgavesettet før du begynner å løse den første oppgaven. Dersom du savner opplysninger 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. Oppgave 1 a) Bruk Thompson s konstruksjon til å lage en NFA for det regulære uttrykket (aa b)*(a cc)* b) Skriv følgende NFA ut som et regulært uttrykk: a 2 a a ε 1 3 b b 4 b c) Gjør om NFAen fra pkt b) til en DFA. 1

2 Oppgave 2 Betrakt følgende grammatikk G 1 : E S E num S - S + S ε hvor E og S er ikke-terminalsymboler, E er startsymbol og: +, -, num er terminalsymboler (med vanlig tolkning). a) Beskriv kort hvordan setninger som G 1 kan produsere ser ut, og gi ett eksempel på en setning med 4 terminalsymboler. b) Gi et regulært uttrykk som lager de samme setningene som G 1. c) Gi et kort argument som bestemmer hvike(n) av følgende fem grupper G 1 hører med i: 1. LR(0) 2. SLR(1) 3. LALR(1) 4. LR(1) 5. Ingen av de overstående Hint: Finn ut om G 1 er entydig. Vi skal nå se på en annen grammatikk G 2 : F + F - F num Hvor F er ikke-terminalsymbol (og startssymbol) og +, -, num igjen er terminalsymboler. d) Du skal nå lage LR(0)-DFA-en for G 2 rett fra denne grammatikken hvor du har utvidet grammatikken med en ny produksjon F F (og hvor F nå er startsymbolet). Nummerér hver av tilstandene. e) Ut fra det svaret på d), angi med en kort begrunnelse hvilke(n) type grammatikk G 2 er (jfr. spørsmål c) ovenfor). f) Lag parseringstabellen for G 2 ut fra den typen grammatikk den er. g) Vis hvordan setningen: vil bli parsert ved å skrive opp, som i boka, stakk-innholdet og input for hver av skift- eller reduser-operasjonene du gjør under parseringen. Oppgave 3 a) Det følgende er et fragment av en grammatikk for et språk med klasser: class class name superclass { decls decls decls ; decl decl decl variable-decl decl method-decl method-decl type name ( params ) body type int bool void superclass name 2

3 Ord i kursiv er meta-symboler, ord og tegn i fet skrift er terminal-symboler, mens name representerer et navn som scanneren leverer. Det kan antas at name har attributtet name. Metoder med samme navn som klassen er konstruktører, og det gjelder følgende regel: Konstruktører må være spesifisert med typen void Lag semantiske regler for hver regel i følgende fragment av en attributtgrammatikk. Sett først opp hvilke attributter du trenger Hint: Du kan klare deg uten en hel symboltabell. Grammar Rule Semantic Rule class class name { decls decls decls ; decl decls decl Decl variable-decl Skal ikke fylles ut Decl method-decl method-decl type name ( params ) body Type int Type bool Type void (skriv av tabellen og fyll den ut på et innføringsark; fyll ikke direkte inn på oppgavearket) b) Anta ta vi har et språk med klasser og subklasser. Alle metoder er virtuelle, slik at de kan redefineres i subklasser. Gitt følgende klassedefinisjoner: class A { int i; void P {... AP...; void Q {... AQ...; class B extends A { int j; void Q {... BQ...; void R {... BR...; class C1 extends B { void P {... C1P...; void S {... C1S...; 3

4 class C2 extends B { int k; void R {... C2R...; void T {... C2T...; Vis hvordan objekter av klassene C1 og C2 vil være strukturert (layout) og tegn virtuell-tabellen for hver av klassene. Bruk navnene i metodekroppene over til å angi elementene i virtuell-tabellene. c) Vi innfører nå muligheten for å kunne spesifisere en metode til å være final. Det skal bety, som i Java, at den ikke lenger er virtuell, dvs at den ikke kan redefineres i subklasser. Anta at vi i klassen B spesifiserer metoden Q til å være final. Må vi da endre på virtuell-tabellen for B-objekter? Begrunn svaret. d) Vi innfører nå operatoren instanceof som i Java: Det boolske uttrykket <refexpr> instanceof <class> er True hvis objektet som <refexpr> peker på har en klasse som ikke er null, og som er klassen <class> eller en subklasse av klassen <class>, ellers False. For å kunne implementere denne operatoren utvider vi virtuell-tabellen med en peker til klassedeskriptoren, som det er en av for hver klasse i programmet. Klassedeskriptoren har da en variabel super, som peker til klasse-deskriptoren for superklassen. Klasser uten eksplisitt superklasse har den spesielle klasse Object som super. Eksemplet under viser dette for et objekt av klassen B: klasse deskriptor for B klasse deskriptor for A super klasse deskriptor for Object B-objekt vt cl super Skisser algoritmen som beregner verdien av <refexpr> instanceof <class>. e) For å effektivisere testen på instanceof innfører vi (inspirert av display/kontekst vektor for nestede blokker) at en klassedeskriptor har en tabell supers, som inneholder alle superklassene for klassen samt klassen selv. Denne tabellen har som indeks klassens subklassenivå startende med 0 for Object, 1 for rotklassen i et subklassehierarki, 2 for neste nivå, osv. I vårt eksempel har klassen A subklasseniv1, B har 2, C1 og C2 har begge 3. For klassene A og B ser klassedeskriptorene med supers-tabellene slik ut: 4

5 Du skal forklare hvordan denne tabellen kan effekstivisere instanceof-testen, og til å illustrere dette skal vi innføre ytterligere to klasser: class C11 extends C1 {... class C21 extends C2 {... Lag supers-tabellene for klassedeskriptorene for C11 og C21, og vis hvordan følgende tester gjøres: rc11 = new C11; rc11 instanceof C1 (1) rc11 instanceof C2 (2) o 0 o Slutt på oppgavesettet lykke til! Arne Maus og Birger Møller-Pedersen 5

6 UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i : INF5110 Eksamensdag : Tirsdag 6. juni 2006 Tid for eksamen : Oppgavesettet er på : 5 sider Vedlegg : Intet Tillatte hjelpemidler : Alle trykte og skrevne Les gjennom hele oppgavesettet før du begynner å løse den første oppgaven. Dersom du savner opplysninger 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. Oppgave 1 Det følgende er et fragment (dvs ikke-interessante deler av grammatikken er ikke tatt med) av en grammatikk for et språk med prosedyrer. Alle prosedyrer har én parameter, og den er enten by value, by reference (keyword ref), eller by-value-result (keyword result). procedure proc id (param) stmt param type id ref type id result type id call id(exp) exp id exp id[exp] exp exp aritop exp Følgende programmer erklærer begge en integer variabel i og en prosedyre change, og programmene assigner 1 til i, kaller prosedyren change(i) og skriver ut verdien av i. Forskjellen er at Program 1 har prosedyren med call by reference, mens Program 2 har prosedyren med call by value result. Språket følger vanlige statiske skopregler. Program 1: { int i; proc change(ref int p) { p=2; i=0; ; i=1; change(i); write(i) 1

7 Program 2: { int i; proc change(result int p) { p=2; i=0; ; i=1; change(i); write(i) 1a Anta at semantikken for by-value-result er slik at adressen (location) til den aktuelle parameter beregnes ved prosedyrekallet (procedure entry). Hva skriver Program 1 og Program 2 ut når de utføres? 1b Anta at semantikken for by-value-result er slik at adressen (location) til den aktuelle beregnes på nytt ved avslutning av prosedyrekallet (prosedyre exit). Hva skriver Program 1 og Program 2 ut når de utføres? 1c Den enkle reglen i dette språket er at prosedyrer med en parameter by reference eller by-valueresult bare kan kalles med et uttrykk som enten er en enkel variabel (id) eller en indisert variabel (id[exp]). Fyll ut de tomme felter i følgende attributtgrammatikk slik at attributtet ok for call er true hvis kallet er gjort ifølge denne regel, ellers false. Symboltabellen er innrettet på akkurat denne reglen, slik at navn på prosedyrer er assosiert med en verdi som sier om denne prosedyre har en parameter by reference (verdien ref), by valueresult (verdien result) eller by value (value). lookupkind(id.name)gir verdien som svarer til hvordan prosedyren med navn id.name er definert. Det er ikke behov for å sjekke om prosedyrenavnet (id) i en call-setning faktisk er deklarert. Grammar Rule procedure proc id (param) stmt Semantic Rule insert(id.name, param.kind) param type id param ref type id param result type id call id (exp) call.ok = exp 1 id [exp 2 ] exp id exp 1 exp 2 aritop exp 3 2

8 Oppgave 2 Betrakt følgende grammatikk G, hvor S og T er ikketerminal-symboler, # og a er terminalsymboler, og S er startsymbolet. S TS S T T #T T a a) Finn First og Follow-mengdene til T og S (og la $ betegne end-of-file som i boka). b) Formulér med dine egne ord hvilke sekvenser av terminalsymboler du kan lage ut fra S. c) Avgjør om du kan lage et regulært uttrykk som uttrykker disse sekvensene av # og a som du kan utlede fra S, og hvis svaret er ja, gi et slikt regulært uttrykk. d) Innfør et nytt start-symbol S S og lag LR(0)-DFA-en for G rett fra denne grammatikken. Nummerér tilstandene. e) Gi et kort argument som bestemmer hvike(n) av følgende fem grupper G hører med i: a. LR(1) b. LALR(1) c. SLR(1) d. LR(0) e. Ingen av de overstående. Hint: Finn ut hvilke mulige konflikter du har i DFA-en og/eller om grammatikken er entydig.. f) Lag parseringstabellen for G ut fra den typen grammatikk den er. g) Vis hvordan setningen: a#a vil bli parsert ved å skrive opp, som i boka, stakk-innholdet og input for hver av skift- eller reduser-operasjonene du gjør under parseringen. Få også med numrene til tilstandene på stakken (som i boka). 3

9 Oppgave 3 3a Anta ta vi har et språk med klasser og subklasser. Alle metoder er virtuelle, slik at de kan redefineres i subklasser. Klassen Graph definerer (sammen med klassene Node, Edge) grafer som består av Node-objekter som er forbundet med Edge-objekter. Et objekt av klassen Graph representerer en graf. Alle noder i en graf antas å være forbundet via attributen startnode, som er en referanse til ett Nodeobjekt. Deler av klassedefinisjoner som ikke er signifikante for oppgaven er antydet med... class Node{... class Edge{... class Graph { Node startnode; void connect(node n1,n2) {... connects two Nodes by creating an Edge-object...; De følgende klasser definerer subklasser (City og Road) til henholdsvis Node og Edge, en subklasse (RoadAndCityGraph) til Graph, og en subklasse (TravelingSalesmanGraph) til RoadAndCityGraph. Metoden display vil tegne grafen med utgangspunkt i startnode. class City extends Node { String name;... class Road extends Edge { String name; int distance;... class RoadAndCityGraph extends Graph { String country; void connect(node n1,n2) {... connects two City objects (treated as Nodes), by creating a Road object... ; void display() {... displays Roads and Cities with names...; class TravelingSalesmanGraph extends RoadAndCityGraph { void display() {... displays Cities with names, and Roads with name and distance... ; Vis hvordan objekter av klassene Graph, RoadAndCityGraph og TravelingSalesmanGraph vil være strukturert (layout) og tegn virtuell-tabellen for hvert av objektene. Bruk navn av formen <klassenavn>::<metodenavn> til å angi hvilken definisjon som gjelder for hvert objekt. 4

10 3b Anta at klassene Node og Edge er definert som indre klasser til klassen Graph, og at slike indre klasser kan redefineres i subklasser, på samme måte som virtuelle metoder. Vi kan altså snakke om at indre klasser er virtuelle klasser. Redefinerte klasser blir automatisk subklasser av de tilsvarende virtuelle klasser; f.eks. vil klassen Node i RoadAndCityGraph være en subklasse til klassen Node i Graph. class Graph { class Node{... class Edge{... Node startnode; void connect(node n1,n2) {... connects two Nodes by creating an Edge-object...; class RoadAndCityGraph extends Graph { class Node { String name;... class Edge { String name; int distance;... String country; void connect(node n1,n2) {... connects two Node objects by creating an Edge-object... ; void display() {... displays Edges and Nodes with names...; class TravelingSalesmanGraph extends RoadAndCityGraph { void display() {... displays Edges and Nodes with names, and Edges with distance... ; På samme måte som virtuell-tabellen for virtuelle metoder brukes ved kall på virtuelle metoder, så vil man nå også trenge en annen virtuell-tabell ved generering av objekter av virtuelle klasser. F.eks. innholder metoden connect i klassen Graph en generering av et Edge-objekt. Hvis denne metoden kalles i et RoadAndCityGraph-objekt, skal man generere et Edge-objekt slik det er definert i klassen RoadAndCityGraph. Vis hvordan en slik virtuell-tabell for virtuelle klasser kan se ut. Ikke ta med virtuell-tabellen fra spørsmål 3a. Forklar hvordan man bruker virtuell-tabellen ved utførelse av new Edge() i metoden connect i klassen Graph o 0 o Slutt på oppgavesettet lykke til! Arne Maus og Birger Møller-Pedersen 5

11 Eksamen i : MED SVARFORSLAG UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet INF Kompilatorteknikk Eksamensdag : Onsdag 1. juni 2011 Tid for eksamen : Oppgavesettet er på : Vedlegg : Tillatte hjelpemidler : 7 sider (pluss vedlegg) 1 side (side 8 rives ut, fylles ut og leveres i hvit besvarelse) Alle trykte og skrevne Les gjennom hele oppgavesettet før du begynner å løse oppgavene. Dersom du savner opplysninger i oppgavene, 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. Oppgave 1 (25%) Vi skal se på et antall grammatikker, nemlig følgende: i. A b A c ε ii. A b A b b iii. A b A b c 1a Her er A startsymbol og eneste ikke-terminal, mens b og c er terminaler. For hver av de tre grammatikkene: Beregn First og Follow til A, tegn LR(0)-DFA en (etter utvidelese med A A), og angi om den er en SLR-grammatikk eller ikke. Angi også hvilke av grammatikkene, om noen, som er LR(0)-grammatikker. Svar 1a Grammatikk i: A b A c ε First(A) = { b, ε Follow(A) = { c, $

12 0 1 A A A. A. A A. b A c A b A b. A c A. b A c A. A A b A. c c A b A c. b SLR(1): Det kunne være tilstand 2 som gav problemer, men siden b (eneste terminal-kant ut av tilst. 2) ikke er med i etterfølger-mengden til A, så går det bra. LR(0): Nei. Både i tilstand 0 og 2 må man lese neste tegn for å avgjøre hva man skal gjøre. Grammatikk ii: A b A b b First(A) = { b Follow(A) = { b, $ 0 1 A A A. A. A A. b A b A. b SLR(1): Nei. Siden b er med i etterfølgermengden til A vet vi ikke om vi skal redusere eller skifte i tilstand 2. LR(0): Nei. Når den ikke er SLR(1) er den heller ikke LR(0) Grammatikk iii: A b A b c First(A) = { b, c Follow(A) = { b, $ 0 1 A A A. A. A A. b A b A. c c A c b A b. A b A b. A. b A b A. b A A b A. b c A b A b. b b A c A b. A b A b A. b A b A b. c A. b A b A. c b SLR(1): Ja, den er faktisk LR(0) som angitt under, og da er den også SLR(1) LR(0): Ja, for i hver tilstand er det bare snakk om enten å skifte eller å redusere. 2

13 1b For hver av de tre grammatikkene, avgjør om grammatikken er LR(1). Det er her mulig å avgjøre dette og forklare det uten å tegne opp LR(1)-DFA en, men det er også en OK besvarelse om du tegner opp denne og avgjør det ut fra den. Svar 1b Grammatikk i: Siden grammatikken er SLR(1) er den også LR(1) Grammatikk ii: Denne er ikke LR(1). Under en parsering etter denne grammatikken skal man gå over fra å skifte til å redusere når vi har lest inn den midterste b-en, men vi kan ikke generelt vite når vi er der om vi bare kan lese ett tegn framover. Grammatikk iii: Siden grammatikken er LR(0) er den også LR(1) 1c Angi for hver av grammatikkene over om det språket de genererer er regulært, og for de som er det skal du angi et regulært uttrykk for språket. For de grammatikker du mener ikke genererer et regulært språk, forklar hvorfor. Svar 1c Grammatikk i: Den generelle formen for en setning er først null eller flere b-er, som er fulgt av like mange c-er, og dette språket er ikke regulært. Det er vel OK bare å vise til at det er angitt på foilene et sted (i en fasit?) at språk der man skal ha like mange sånne som slike (f.eks. ((((())))) ) ikke er regulære. Ellers kan man f.eks. argumentere slik: Et språk er som kjent regulært hvis og bare hvis man kan parsere det ved bare å huske en endelig mengde informasjon om den delen man har lest (eller være i én av et endelig antall tilstander) når man leser fra venstre mot høyre. Men i grammatikk i må man kunne huske hvor mange b-er man har lest når man finner første c, og det antallet kan være ubergrenset stort. Grammatikk ii: Den generelle setningen her er rett og slett et odde antall b-er. Dette språket er regulært siden det kan beskrives ved følgende regulære uttrykk b ( b b )* Grammatikk iii: Den generelle setningen her er to sekvenser med like mange b-er, og med en c i midten. Dette språket er ikke regulært, av samme grunn som for grammatikk i. 1d Tegn opp en parseringstabell for grammatikk i, og sørg for at den blir uten konflikter. Angi så en steg-for-steg LR-analyse av setningen bbcc, på samme måte som øverst på side 213 i boka (tabell 5.8). 3

14 Svar 1d Ut fra LR(0)-DFA en og de SLR(1)-betrakninger som er gjort over, får vi følgende entydige tabell: b c $ A s2 r(a ε) 1 1 accept 2 s2 r(a ε) r(a ε) 3 3 s4 4 r(a bac) r(a bac) Parseringen blir da som følger: $ 0 b b c c $ $ 0 b 2 b c c $ $ 0 b 2 b 2 c c $ Så skjer det mest interessante: $ 0 b 2 b 2 A 3 c c $ $ 0 b 2 b 2 A 3 c 4 c $ $ 0 b 2 A 3 c $ $ 0 b 2 A 3 c 4 $ $ 0 A 1 $ Og dette gir accept Oppgave 2 (20%) Anta at vi har et objekt-orientert språk, hvor en virtuell metode i en klasse kan redefineres ( overriding ) i en subklasse av denne klassen. En virtuell metode deklareres med en virtual modifier, mens en redefinisjon deklareres med modifieren redef. Metoder uten virtual er vanlige metoder og kan altså ikke redefineres. Merk at dette ikke er helt som i Java. I Java er alle metoder virtuelle, mens her gjelder det bare de som har modifieren virtual. Det følgende er klasser definert i dette språket: class A { virtual void m(int x,y){... void p(){... virtual void q(){... class B extends A{ redef void m(int x,y){... void r(){... class C extends A{ redef void q(){... class D extends B{ redef void m(int x,y){... class E extends B{ redef void q(){... class F extends C{ redef void m(int x,y){... 4

15 2a Vi antar nå først at klassen for et gitt objekt bestemmer, på vanlig måte, hvilken versjon av en virtuell metode som kalles. Lag virtuell-tabellene for klassene A, B, C, D,E og F. For hvert element i tabellene skal du bruke notasjonen A::m for å angi hvilken metode som gjelder. Indeksen i disse tabeller starter på 1. Svar 2a 2b I resten av oppgaven skal vi for virtuelle metoder ha den semantikk at en redefinert virtuell metode, for eksempel m, skal, som det første den gjør, kalle den tilsvarende virtuelle eller redefinerte metode (dvs m ) i den nærmeste superklasse som har en slik, før den utfører sin egen body. Dette vil i sin tur føre til at redefinerte eller virtuelle metoder m i videre superklasser utføres. Dette kunne man implementere ved å sette inn det riktige kall som første statement i bodies på redefinerte metoder. Men semantikken rundt parameteroverføring skal her være litt spesiell slik at denne enkle måten ikke vil fungere. Parametrene som gis med i det opprinnelige kallet skal nemlig gå direkte som parametre til den metoden som utføres først, altså den som er merket virtual i programmet. Når denne er ferdig utført skal de verdiene som da står i dens parametervariable overføres som aktuelle parametre til den neste dypere redefinerte metode, osv. Dette gjør at stakken av kall må settes opp først, og de aktuelle parametre må gis til den første virtuelle metode som skal utføres. Hvis for eksempel m kalles med m(1,2) på et D-objekt, så skal stakken settes opp og de aktuelle parametre gis til aktiveringsblokken tilsvarende A::m, og utførelsen skal starte med utførelsen av A::m. Ved exit av A::m skal verdiene av parametrene x og y gis som aktuelle til den versjon av m som da skal utføres. For å implementere denne nye semantikk utvides virtuell-tabellen, slik at det for hvert indeks blir en liste av metode-angivelser. Denne listen vil dermed angi sekvensen av de metoder som skal kalles. Tegn de nye virtuell-tabeller for klassene D og F. Tabellene for B og C er gitt under. For metodeangivelser brukes samme notasjon som før. 5

16 Svar 2b 2c I denne del av oppgaven skal du skissere hvordan stakken i 2b kan lages ved hjelp av de nye virtuell-tabeller. Du kan anta at du har en run-time rutine makeactivationrecord(metode). Denne tar som parameter en metode-angivelse (for eksempel A::m) med nok informasjon til å lage en aktiveringsblokk med riktig størrelse, men du skal skissere hvordan control-link og retur-adresse settes i aktiveringsblokken. Anta at den aktuelle virtuell-tabell holdes i en variabel med navn vt, den aktuelle metoden holdes i en variabel method, og funksjonen index(method) gir deg index i vt. Anta videre at inngangen i tabellen gir en peker til første metode-angivelse, og at hver av disse har en next peker. For metodeangivelsen som svarer til den virtuelle metode hvor den defineres for første gang (i eksemplet her m i A) er denne peker none. Du kan gjerne illustrere resultatet for et kall m(1,2) på et D-objekt, men om resten er riktig er det OK uten. 6

17 Svar 2c caller = fp; method = vt(index(method)); while method =/= none do { ar = makeactivationrecord(method); ar.conrollink = caller; ar.returadresse = første statement i metoden som tilsvarer fp method = method.next; caller = ar; 2d Overføring av parametre mellom de enkelte utførelser av en virtuell metode kan åpenbart ikke gjøres som en del av det å sette opp stakken i 2c, men må gjøres ved bl.a. å sette inn ekstra kode i metoder merket virtual eller redef. Du må også innføre en ekstra variabel i de aktuelle aktiveringsblokkene. Hvilken kode skal settes inn og hvor? Koden kan gjøre bruk av alle deler av den aktuelle aktiveringsblokk. Svar 2d Utfør følgende kode, som det siste før exit, i alle aktiveringer bortsett fra den dybeste: controllink.x = x controllink.y = y Oppgave 3 (30%) Det følgende er et fragment av en grammatikk for et språk med klasser. En klasse kan ikke ha noen superklasse, men den må implementere en eller flere interfacer: class class name implements interfaces { decls decls decls ; decl decl decl variable-decl method-decl method-decl type name ( params ) body type int bool void interfaces interfaces, interface interface interface name Ord i kursiv er ikke-terminaler, ord og tegn i fet skrift er terminal-symboler, mens name representerer et navn som scanneren leverer. Det kan antas at name har attributtet name. Det som er spesielt med dette språk er at de av en klasses metoder som har samme navn som en av interfacene klassen implementerer er konstruktører for klassen. Det kan i klassen gjerne være flere metoder, som har samme navn som et interface, men da med forskjellige parametre; dette er imidlertid ikke temaet i denne oppgave. Generering av objekter har formen new <classname>.<interface-name>(<actual parameters>), da forskjellige klasser kan implementere samme interfacen. En krav i dette språket er at konstruktører må være spesifisert med typen void, og det er dette kravet som skal sjekkes med de semantiske regler du skal sette opp. Lag semantiske regler for dette kravet i følgende fragment av en attributtgrammatikk. 7

18 For å lage reglene kan du bruke de funksjoner og de mengder du trenger, bare du definerer dem. Besvar dette spørsmålet ved å bruke vedlegget side 8. 8

19 Grammar Rule Semantic Rule class class name implements interfaces { decls decls 1 decls 2 ; decl decls decl decl method-decl method-decl type name ( params ) body type int type bool type void type.type = int type.type = bool type.type = void interfaces 1 interfaces 2, interface interfaces interface interface name interface.interfacename = name Svar 3 9

20 Grammar Rule class class name implements interfaces { decls Semantic Rule decls.setofinterfacenames = interfaces.setofinterfacenames decls 1 decls 2 ; decl decls 2.setOfInterfaceNames = decls 1.setOfInterfaceNames decl.setofinterfacenames = decls 1.setOfInterfaceNames decls decl decl.setofinterfacenames = decls.setofinterfacenames decl method-decl method-decl.setofinterfacenames = decl.setofinterfacenames method-decl type name ( params ) body type int type bool type void interfaces 1 interfaces 2, interface interfaces interface interface name if methoddecl.setofinterfacename.has(name.name) then if (not(type.type = void))then error( constructor not of type void ) type.type = int type.type = bool type.type = void interfaces 1.setOfInterfaceNames= interfaces 2.setOfInterfaceNames + [interface.interfacename] interfaces.setofinterfacenames.insert( interface.interfacename) interface.interfacename= name Oppgave 4 (25%) (Jeg kunne her tenke meg at hver av oppgavene får samme % etter oppdeling av 4a i 4a1 og 4a2, altså 5% på hver). Vi skal her se på verifikasjon (omtrent som i en Java/JVM-loader) av en enkel type P-kode. Den har få instruksjoner, og alle verdier er heltall. Vår P-kode utføres på vanlig måte, med en stakk med verdier under utførelsen. Under er v en programvariabel, og L er adressen til et sted i programmet. Vår spesielle P-kode har følgende instruksjoner: lda v ldv v ldc k add Henter adressen til variablen v opp på toppen av stakken. En adresse er også et heltall. Henter verdien av variablen v opp på toppen av stakken Henter konstanten k opp på stakken Legger sammen de to øverste verdier på stakken, fjerner (popper) dem fra stakken og legger svaret på toppen av stakken. 10

21 sto Her tolkes det som ligger på toppen av stakken som en verdi, og det nest øverst som en adresse. Instruksjonen kopierer verdien inn til den angitte adressen i lageret, og popper både verdien og adressen. jmp L Hopp til program-adressen L jge L (og likeledes: jgt L, jle L, jlt L, jeq L, jne L) Denne instruksjonen er litt enklere enn vanlig, nemlig slik: Om verdien på toppen av stakken er større eller lik 0 så hoppes det (og tilsvarende for de andre fem). Verdien på toppen av stakken poppes uansett om det hoppes eller ikke. lab L Angir at program-adressen L er på dette stedet i programmet. 4a (Jeg ser at denne burde vært delt i to oppgaver, og under kommer først den opprinnelige oppgaven, og så den oppdelte utgaven (delt i 4a1 og 4a2). Merk at den siste setningen i den opprinnelige er tatt med i 4a1, men den ble vel egentlig et litt dummy spørsmål) (Opprinnelig 4a:) Vi tenker oss at vi skal lage en verifikator for programmer i vår P-kode (altså for sekvenser av P-instruksjoner). Angi flest mulig ting som denne verifikatoren bør/kan teste angående et gitt slikt program, og skisser hvilke datastrukturer m.m. du vil bruke for å utføre testen. Beskriv tingene direkte i forhold til vår spesielle P-kode. Et program skal både starte og avslutte med tom stakk. Du kan anta at programmets hoppinstruksjoner faktisk går til en instruksjon i programmet, så dette behøver du ikke teste Forklar også i hvilken forstand et P-kode-program er riktig om det passerer testen din. 4a1 (Oppdelt utgave) Vi tenker oss at vi skal lage en verifikator for programmer i vår P-kode (altså for sekvenser av P- instruksjoner). Angi flest mulig ting som denne verifikatoren bør/kan teste angående et gitt slikt program. Forklar også i hvilken forstand et P-kode-program er riktig om det passerer testen din. Svar 4a1 Alt som skal på stakken er her heltall (også adresser), så verifikatoren kan ikke se noen typemessig forskjell på forskjellige stakker. Det eneste den kan se på er størrelsen av stakken. Vi vet at vi skal starte med tom stakk på toppen av programmet, og det er naturlig å sjekke følgende tre ting: - At det alltid er nok elementer på stakken til å gjøre en angitt operasjon. For eksempel må de være minst to elementer på stakken for å gjøre en add-operasjon, og minst ett element for å gjøre en jge-instruksjon. - Sjekke at stakken er tom ved slutten av programmet. - Når man gjør et hopp til en gitt label L (eller kommer til lablen L fra forrige instruksjon) skal stakken alltid ha samme størrelse. Om et program er kommet vel gjennom denne testen vet vi at stakken alltid vil ha de nødvendige heltall på stakken når en operasjon skal utføres, og det gjelder samme hvilken vei man går gjennom programmet. 4b2 (Oppdelt utgave) Skisser hvilke datastrukturer m.m. du vil bruke for å utføre testen. Beskriv tingene direkte i forhold til vår spesielle P-kode. Et program skal både starte og avslutte med tom stakk. Du kan anta at programmets hoppinstruksjoner faktisk går til en instruksjon i programmet, så dette behøver du ikke teste. Svar 4a2 (Det var jo egentlig bare spørsmål etter datastrukturen, men for å forstå den må man jo 11

22 også kjenne bruken. Om datastrukturen og antydninger av hvordan den skal brukes henger sånn rimelig sammen, så skal vi vel ikke forlange så mye mer) Det er det siste punktet i svaret på 4a1 som krever litt ekstra, og man bør ved hver lab L i programmet gjøre plass til en liten data-record som her kalles S(L) ( status ved L) som har én variabel SD (stakkdybde, som fra starten er -1) og en boolsk variabel SV (som fra starten er FALSE, og som sier om man har sjekket programmet videre fra L). Dessuten trenger vi en global mengde av labler som vi kaller LabelKurven. Utføring av verifikasjonen: De to første punktene over går greit å sjekke ved bare løpende å holde greie på stakkdybden mens man utfører programmet. Selve testen startes så med tom stakk, og man begynner å utføre programmet fra toppen f.eks. slik som angitt under. (Dette er egentlig bare et søk gjennom alle kantene i en graf, der de betingede hoppene er noder med to ut-kanter, og der labler er noder med flere inn-kanter. Søket kan også godt gjøres rekursivt, men under gjøres det mer som bredde først. Hoved-vitsen er altså å sjekke at alle veier til hver node har samme stakkdybde): - Man har altså en løpende stakkdybde (heltall), og ved hver instruksjon gjør man de forandringer av denne som den aktuelle instruksjonen foreskriver (og man sjekker hele tiden at det alltid er nok elementer på stakken til den aktuelle instruksjonen, ellers forkastes programmet). - Ved hver lab L -instruksjon gjør man følgende test: Anta at stakkdybden langs den veien du har fulgt vil være sd ved L. Dersom lablens SD er -1, setter vi SD til sd (dette er første gang vi hører om denne lablen, og vi angir at vi nå har sett en vei dit som har stakkdybde SD=sd). Ellers tester vi at sd er lik SD, og om det ikke stemmer skal programmet forkastes (det finnes da to veier til lablen som har forskjellige SD). Til slutt sjekker vi om S(L).SV er FALSE, og i så fall setter vi den til TRUE, og fortsetter på vanlig måte. Om S(L).SV er TRUE avslutter vi sjekken på dette punkt (det er gjort allerede), og henter en label L (med S(L).SV = FALSE) fra Label- Kurven. Om kurven er tom er vi ferdig med hele sjekken, ellers går vi til L, setter vår løpende stakkdybde til S(L).SD, setter S(L).SV til TRUE, og fortsetter på vanlig måte. - Om man kommer til et betinget hopp til L ser man først på S(L).SD og gjør en test av denne slik som angitt i forrige punkt. Om S(L).SV = FALSE legger vi L i LabelKurven (vi må starte herfra senere). Deretter fortsetter man på vanlig måte med instruksjonen etter det betingede hoppet. - Om man kommer til et ubetinget hopp jmp L gjør man også først den samme testen som angitt over. Om S(L).SV er FALSE setter vi den til TRUE og fortsetter sjekken fra L med den aktuelle stakkdybden. Om S(L).SV er TRUE gjør vi som over: Vi avslutter sjekken på dette punkt, og henter en label L (med S(L).SV = FALSE) fra Label-Kurven. Om kurven er tom er vi ferdig med hele sjekken, ellers går vi til L setter vår løpende stakkdybde til S(L).SD, setter S(L).SV til TRUE, og fortsetter på vanlig måte. 12

23 4b Under står tre programmer i vår P-kode. Sjekk for hver av dem om de passerer testen din, og angi hva som eventuelt går galt om de ikke gjør det. Program 1: lda x ldv y ldv z jge L1 add add ldc 5 lab L1 ldc 8 sto Program 2: lda x ldv y ldv z jge L1 ldc 5 add lab L1 sto Program 3: lda x ldv y ldv z jge L1 ldc 5 add ldv u lab L1 sto Svar 4b Det første programmet er galt fordi det bare vil være ett element på stakken ved den siste addinstruksjonen. Det andre programmet er OK Det tredje programmet er galt fordi de to veiene som fører til lablen L1 gir stakkdybde 3 (uten hopp) og 2 (med hopp). 4c Vi vil oversette vår P-kode til maskinkode for en maskin der alle operasjoner (inkl. sammenlikninger) må gjøres mellom verdier som ligger i registre, og der kopiering mellom lageret 13

24 og registre bare kan gjøres med egne LOAD- og STORE-instruksjoner. Under oversettelsen har vi en stakk med diskriptorer. Vi skal se på det å oversette P-instruksjonen ldv v. Spørsmålet er om det da er fornuftigst å produsere en LOAD-instruksjon som henter verdien av variabelen v opp i et register, eller om det er best bare å legge en diskriptor på stakken som sier at denne verdien ligger i variabelen v. Drøft dette ut fra forskjellige forutsetninger, f.eks. ut fra hva språket som vi oversetter fra lover om rekkefølgen ved beregning av uttrykk (men også ut fra andre ting som du mener er aktuelle). Svar 4c Grovt sett: Dersom språk-reglene sier at man må utføre uttrykk i rekkefølge fra venstre mot høyre, så må man lage LOAD-instruksjon fra v (program-variabel) til et register med en gang. Om man er fri til å beregne uttrykket i vilkårlig rekkefølge er det lurt å lage en diskriptor. Da står man fritt til å vente med opphentingen til en operasjon faktisk trenger den verdien, slik at den ikke har tatt opp et register fram til den faktisk skal brukes. Her kan man optimalisere mye ved f.eks. å sjekke om det finnes noen prosedyrekall i det aktuelle uttrykket slik at verdier på variable kan forandre seg. 4d Vi vil igjen oversette vår P-kode til maskinkode, slik som i oppgave 4c, og vi skal anta at vi skal oversette én og én basal blokk, og at alle registre skal tømmes på kontrollert måte etter utførelsen av en basal blokk. Spørsmålet her er hvilke data diskriptorene på stakken skal inneholde, og hva du eventuelt trenger av andre typer diskriptorer. Vi antar at vi kan tillate oss å lete gjennom alle kompilator-stakkens diskriptorer hver gang vi lurer på hvor visse verdier er etc., slik at informasjon vi kan finne på denne måten ikke behøver å lagres i ekstra diskriptorer. Forklar også kort hvordan du kan finne den informasjonen du trenger under kodegenereringen, og hvordan du eventuelt vil bruke de ekstra diskriptorene du vil ha. Svar 4d Diskriptorene på stakken bør hvertfall inneholde følgende: - Om det er en konstant (og da hvilken), - om det er verdien til en program-variabel (og da hvilken), eller - om det er en verdi som ligger i et register (og i så fall hvilket). Diskriptorene på stakken vil generelt ikke inneholde nok informasjon til å holde orden på hva som er i hvilke registere, om en variabel-verdi er i sin hjemmeposisjon, etc. Dette blir opplagt når man ser at stakken kan bli tom mellom setningene inne i den basale blokken, og at det da fremdeles kan være variabel-verdier som ligger i registre i påvente av at verdiene kanskje skal brukes en gang til. Det fører til at man får omtrent de samme behov som i kodegenererings-algoritmen i boka, og at det kan være greit med både en register-diskriptor og en adresse-deskriptor. Vi skal jo også, ved slutten av den basale blokka, sette alle verdier tilbake til deres hjemmeposisjon i sine variable, og da er disse diskriptorene viktige. Lykke til! Stein Krogdahl og Birger Møller-Pedersen 14

25 Vedlegg til besvarelse av Oppgave 3 Kandidat nr:... Dato:... Grammar Rule Semantic Rule class class name implements interfaces { decls decls 1 decls 2 ; decl decls decl decl method-decl method-decl type name ( params ) body type int type bool type void type.type = int type.type = bool type.type = void interfaces 1 interfaces 2, interface interfaces interface interface name interface.interfacename = name 15

26 Eksamen i : MED SVARFORSLAG UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet INF Kompilatorteknikk Eksamensdag : Onsdag 6. juni 2012 Tid for eksamen : Oppgavesettet er på : Vedlegg : Tillatte hjelpemidler : 6 sider (pluss vedlegg) 1 side (side 7 rives ut, fylles ut og leveres i hvit besvarelse) Alle trykte og skrevne Les gjennom hele oppgavesettet før du begynner å løse oppgavene. Dersom du savner opplysninger i oppgavene, 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 oppgave 3 besvares ved bruk av vedlegg. Oppgave 1 (25%) Vi skal se på følgende grammatikk G1: S a S # S S Her er S startsymbol og eneste ikke-terminal, mens a, # (samt avslutnings-symbolet $) er teminalsymboler. 1.a Gi en konkret begrunnelse for at G1 er flertydig. Svar 1.a Setningen a # a har i det minste to syntakstrær: S S # S S S a S S # S a a a a a 1.b Anta at: - Operasjonen # har lav presedens, og er høyreassosiativ - har høy presedens, og er venstreassosiativ

27 Angi en ny grammatikk G2 som er entydig, som beskriver samme språket som G1 og som gir et syntaks-tre som følger de to reglene over. Du kan innføre nye ikke-terminaler, og du behøver ikke argumentere for at G2 er entydig ut over å vise til at den likner tilsvarende entydige grammatikker i pensum. Svar 1.b Det er to rimelige svar: S -> T + S T T -> F F F -> a S -> T + S T T -> a a Dette er satt opp etter samme prinsipp som på side 119 i læreboka 1.c Vi ser på grammatikkene G1, G2, samt følgende grammatikk G3 (der + er et nytt terminal-symbol): S a S # S S + S + Angi for hver av språkene L(G1), L(G2) og L(G3) om de er eller ikke er regulære. Forklar, og angi et regulært uttrykk for de som eventuelt er regulære. Svar 1.c G1 og G2 er jo samme språket, og det er regulært og kan beskrives f.eks. slik: a ( a)* For G3 er alle setninger som kan dannes med bare «+» og «a» følgende: a +a+ ++a++ +++a+++ Det må her altså være like mange «+»-er både foran og bak «a»-en. Det er kjent fra pensum at et slikt språk ikke er regulært. Ser man på hele språket til G3 vil setningene også inneholde «@» og «#», men «+»-ene vil komme inn på en liknende måte som over, så språket er ikke regulært. 1.d Tegn opp LR(0)-DFA en til den flertydige grammatikken G1 (med vanlig bruk av S ). 2

28 Svar 1.d 0 S ->.S S ->.a S ->.S # S S S a S a 3 S -> S ->.a S ->.S # S S S S -> S. S -> S. # S S -> S a 4 # S -> S #.S S ->.a S ->.S # S S S 2 S -> a. 5 S # 6 S -> S. S -> S. # S S -> S S -> S # S. S -> S. # S S -> S 1.e Beregn First og Follow til S i G1 (med vanlig bruk av $). Angi så hvilke tilstander i DFA en fra 1.d som har: A. konflikter som ikke kan løses med LR(0)-betrakninger, men som kan løses med SLR(1)- betrakninger. Forklar. B. konflikter som ikke kan løses med SLR(1)-betrakninger. Forklar. Svar 1.e First(S) = { a Follow (S) = { $ A. Det er en LR(0)-konflikt i tilstand 1, som kan løses i SLR(1) ved at man reduserer (aksept) ved $, og skifter ved # B. Det er LR(0)-konflikter både i tilstand 5 og 6. Disse kan ikke løses med SLR-betrakninger siden det er aktuelt både å skifte og redusere for # (men om det kommer $ vet vi at det skal reduseres). Kommentar: Vi visste at det her ville bli konflikter som ikke er løselige av noen type LRbetraktninger, siden grammatikken er flertydig. 1.f For tilstandene under punkt B i spørsmål 1.e, angi hvordan du ville løse konfliktene i disse «for hånd», om du skal få den presedensen og assosiativiteten som er angitt i 1.b? Tilsand 5: Her ligger nå S på toppen av stakken. Derfor: For #: Reduser, binder sterkere enn # Reduser, er venstreassosiativ For $: Reduser (ingen konflikt) Tilstand 6: Her ligger nå S # S på toppen av stakken. Derfor: 3

29 For #: Skift, siden # er høyreassossiativ Skift, binder sterkere enn # For $: Reduser (ingen konflikt) 1.g Sett opp en SLR(1)-parseringstabell for L(G1) ut fra svaret på spørsmålene 1.d og 1.f. Tabellen skal altså ha maks én aksjon i hver rute, og den resulterende syntaksanalysen skal altså følge reglene fra 1.b. Svar 1.g a $ S 0 s2 1 1 s4 s3 acc. 2 r(s -> a) r(s -> a) r(s -> a) 3 s2 5 4 s2 6 5 S) S) r(s->s@s) 6 s4 s3 r(s->s # S) Oppgave 2 (25%) 2.a Vi tenker oss i denne oppgaven at vi har et Java-lignende språk hvor metoder kan ha lokalt definerte metoder. Dessuten kan man deklarere variable og metoder også på ytterste programnivå. Dette skal fungere som vanlig i språk som er statisk skopet. Det følgende er et program i dette språket. Oppstart av programmet skjer ved å kalle main-metoden. { class C { void m1(){ void f() {; f(); void m2() { int i; void g() { int j; j=i; ; i=1; rc.m1(); ; ; C rc; void main() { rc = new C (); rc.m2(); Tegn kall-stakken som den ser ut når aktiveringsblokken ( activation record ) for f er på toppen av 4

30 stakken for første gang, inklusive variable, access-linker og control-linker, bortsett fra access-linker for metoder som er direkte deklarert i en klasse (kan da anta at access-linken peker til C-objektet, men dette er ikke viktig for oppgaven). Svar 2.a 2.b I resten av oppgave 2 innfører vi metoder som parametere. Det er en regel at aktuelle parametere til slike må være metoder som er direkte synlige fra kallstedet. Eksemplet over blir så endret slik at f blir en metodeparameter, og kallet på f i m1 blir da et kall på en metodeparameter: { class C { void m1(void f()){ ; f(); void m2() { int i; void g() { int j; j=i; ; i=1; rc.m1(g); ; C rc; void main() { rc = new C (); rc.m2(); Tegn kall-stakken som den ser ut når aktiveringsblokken for kallet rc.m1(g)er på toppen av stakken. Hvordan representeres metoden g i denne aktiveringsblokken slik at kallet på parameteren f (dvs kallet f() i m1) kan utføres? 5

31 Svar 2.b Parameteren f er representert ved et par <ip, ep>, hvor ip peker ut koden for den aktuelle parameteren og hvor ep peker ut aktiveringsblokken for den blokken som tekstlig omslutter definisjonen av den aktuelle parameteren. I det aktuelle kall peker ip ut koden for g og ep peker ut aktiveringsblokken for m2, hvor g er definert. 2.c Tegn kall-stakken som den ser ut når aktiveringsblokken for kallet av f i m1 er på toppen av stakken. Forklar hvordan access-link for aktiveringsblokken på toppen av stakken settes i dette spesielle tilfellet. 6

32 Svar 2.c Oppgave 3 (25%) Det følgende er en del av en grammatikk for et språk med klasser. Det er bare tatt med de produksjoner som har betydning. Klasser har for eksempel også variable, men de er ikke viktige her. class class name { methoddecls methoddecls methoddecls ; methoddecl methoddecls methoddecl methoddecl type name ( parameters ) body parameters parameters, parameter parameters parameter parameter type name type int type bool Den regel som skal spesifiseres ved hjelp av en attributtgrammatikk er at en klasse kan ha flere enn én constructor, men de må ha forskjellige signaturer i form av antall og/eller typer av parametere. Lag attributtgrammatikken basert på ideen om at methoddecl har et attributt constructorname som er satt sammen av navnet på metoden og strenger som tilsvarer typene på parameterne. En constructor C med parametertypene (int, int) vi således få constructorname C_i_i, mens en constructor C med parametertyper (int, bool) vil få constructorname C_i_b. Testen vil derfor 7

33 være, som antydet i første rekke i tabellen under, at alle navne i mengden av constructornavne er forskjellige. Vi innrømmer at dette ikke er det mest optimale, men det er ikke poenget her. Definer de regler som gjør denne testen mulig. Anta at du har funksjoner og operatorer for å innsette navne i en menge og for å konkatenere strenge og tegn. Svar oppgave 3 Grammar Rule class class name { methoddecls methoddecls 1 methoddecls 2 ; methoddecl Semantic Rule class.ok = all names in methoddecls.constructornameset are different methoddecls 1.constructorNameSet = methoddecls 2.constructorNameSet + methoddecl.constructornameset methoddecls methoddecl methoddecls.constructornameset = methoddecl.constructorname methoddecl type name ( parameters ) body parameters 1 parameters 2, parameter methoddecl.constructorname = name.name + _ + parameters.paramtypes parameters 1.paramTypes = parameters 2.paramTypes + _ + parameter.typename parameters parameter parameters.paramtypes = parameter.typename parameter type name parameter.typename = type.typestring type int type bool type.typestring = i type.typestring = b 8

34 Oppgave 4 (25%) En metode med to value-parametere er oversatt til følgende sekvens av TA-instruksjoner. Den eneste typen i språket er heltall. x = <verdien av første aktuelle parameter> (Du kan skrive dette slik: «x = par1») y = <verdien av andre aktuelle parameter> (Tilsvarende) z = x + y label L1 u = x + 1 x = u + y if (y < x) goto L4 // Vi antar at det finnes en TA-instruksjon av denne formen y = u + 1 u = y + x label L2 z = 5 if (x < u) goto L1 x = u + y v = x + y u = v + 1 goto L5 label L4 v = z + 3 x = y + u label L5 z = v + 4 z = x + z return z 4.a Del programmet opp i basale blokker, og tegn opp flyt-grafen for programmet. Sett navnene B0, B1, osv. på blokkene. 9

35 Svar 4.a, 4.b og 4.c 4.c.1: Siden u ikke er med i outlive(b3), så er denne tre-adressesetningen helt uten virkning på resultatet B3 { u y x = u + y v = x + y u = v + 1 goto L5 { v x B0 B1 B2 TOM = Ø x = par1 y = par2 z = x + y { x y z { x y z label L1 u = x + 1 x = u + y if (y < x) goto L4 y = u + 1 u = y + x label L2 z = 5 if (x < u) goto L1 B5 { u x y z { u x { u x y z { v x z = v + 4 z = x + z return z TOM = Ø B4 4.c.2: Siden denne, altså inlive(b0), er tom er det ingen variable som kan tenkes å bli brukt før de har fått verdi { u y z label L4 v = z + 3 x = y + u { v x 4.b: Denne mengden, altså outlive(b2), blir i første omgang bare { u y, men etter at også inlive(b1) er beregnet og blir tilbakeført, får den også x og z 4.b For hver basal blokk, finn hvilke variable som faktisk er i live både foran og etter blokka (altså inlive og outlive for blokka). Du kan bruke metoden fra pensum til å finne svaret, eller gjøre egne betraktninger. Det er greit å enten gi svaret direkte på flytgrafen fra 4.a, eller du kan tegne opp flytgrafen en gang til (gjerne uten kode i nodene) med alle mengdene inlive og outlive satt på der de hører hjemme. 4.c Ut fra informasjonen fra 4.b og detaljene i TA-instruksjonene er det mulig å se (1) om noen av TA-instruksjonene i programmet kan fjernes uten at det forandrer sluttresultatet når programmet utføres. Angi i så fall disse (2) om det er variable som, i en eller annen eksekvering, kan bli brukt før de har fått verdi. Angi i så fall disse. Om du ikke har fått til 4.b kan du likevel forsøke å svare på denne oppgaven enten direkte fra programmet, eller fra flyt-grafen. 10

36 4.d (Er uavhengig av det over) I pensum er det diskutert hvordan man kan lage TA-kode for kortsluttede boolske uttrykk som står som betingelser i if- eller while-setninger. Dette gjøres rekursivt, og den rekursive kodegenererings-metoden har to label-parametere som koden skal hoppe til når man vet at det lokale uttrykket er h.h.v. true eller false. Programmet for dette er gjengitt under. Vi oversatte i pensum til TA-kode og ikke til P-kode bl.a. for å slippe å tenke på at det under beregning av uttykket kan være noe på stakken ved hopp, som kanskje ikke stemmer med det stedet det hoppes til. Vi skal her se nærmere på hvor stort dette problemet blir, og hvordan vi eventuelt kan korrigere for det. Som svar forklar først i detalj hvordan ting vil forholde seg med stakkdybder under uttrykksberegningen, og skissér så hvordan dette kan håndteres under kodegenereringen, gjerne ved å henvise til koden under. Merk: Vi antar at P-koden skal lages slik at stakken under kjøring er tom mellom setninger, og at den derved er tom når beregningen av det boolske uttrykket starter. Hint: Det er sikkert lurt å se på hvordan P-koden blir for noen konkrete boolske uttrykk. Program fra pensum. Det genererer TA-kode for logiske uttrykk i if- og while-setninger: void genboolcode(string labt, labf) { case : { String labx = genlabel(); left.genboolcode(labt, labx); emit2( label, labx); right.genboolcode(labt, labf); case && : { String labx = genlabel(); left.genboolcode(labx, labf); emit2( label, labx); right.genboolcode(labt, labf); case not : { // Har bare left -subtre left.genboolcode(labf, labt); case < : { String temp1, temp2, temp3; temp1 = left.genintcode(); temp2 = right.genintcode(); temp3 = genlabel(); emit4(temp3, temp1, «lt», temp2); // Lager instruksjonen: temp3 = temp1 < temp2 emit3(«jmp-false», temp3, labf); emit2(«ujp», labt); 11

37 Svar 4.d Saken her er at så lenge man skal generere kode som kortslutter de boolske uttrykkene så blir det ingen problemer med stakkdybden i det hele tatt. Det kommer av at man, så fort det er en boolsk verdi på stakken, vil teste om denne er true/false, og enten hoppe eller fortsette rett til neste instruksjon. Teste-instruksjonen er slik at den i begge tilfelle vil ta bort det som er på toppen av stakken, og dermed vil det aldri bygge seg opp noe på stakken. Vi kan se på følgende eksempel, der a, b c og d er boolske variable. Beregningen vil da følge pilene, ut fra at alle grener som ligger over teksten er TRUE-grener, og de under er FALSE-grener: if ( a and b ) or ( c and d ) then else... Her vil stakken alltid være tom når kontrollen går langs en kant, og ved hver av variablene blir denne variabelen pushet på stakken, men forsvinner igjen i og med TRUE/FALSE-testen Dette betyr at en kodegenererings-prosedyre som skal lage P-kode kan lages etter nøyaktig samme mal som den angitt i oppgaven som lager TA-kode. Vi behøver ikke tenke på stakkdybden i det hele tatt. 12