Yderligere udvidelser af oversætter for Minimal

Transkript

1 Yderligere udvidelser af oversætter for Minimal Karakteropgave på kurset Oversættere Vinter Introduktion Dette er den anden del af rapportopgaven på Oversættere, vinter Opgaven skal løses individuelt. Opgaven bliver stillet mandag d. 2/ kl og skal afleveres i 2 eksemplarer i førstedelsadministrationen senest fredag d. 13/ kl Denne del af rapportopgaven bedømmes med ekstern censur til en karakter i trettenskalaen. Godkendelsesopgaven er en forudsætning for karakteropgaven, så hvis man ikke har afleveret godkendelsesopgaven eller fået denne godkendt, så kan man ikke få sin karakteropgave bedømt. Ligeledes vil karakteren for karakteropgaven ikke blive registreret på eksamenskontoret før den skriftlige eksamen er bestået. Eksamen og rapportopgave kan bestås i forskellige eksamensterminer. Karakteropgaveteksten angiver fem forskellige opgaver. Hver deltager skal løse en af disse opgaver, og det skal af besvarelsen klart fremgå, hvilken opgave, der er søgt løst. Det er endvidere et krav, at personer, der var i samme gruppe til godkendelsesopgaven, løser forskellige opgaver til karakteropgaven. 2 Om opgaven I dokumentet Sproget Minimal er et simpelt funktionelt sprog beskrevet. Dette blev i godkendelsesopgaven udvidet med en række faciliteter beskrevet i dokumentet Udvidelser af oversætter for Minimal. I filen G-sol.zip (som findes i kataloget /usr/local/del1/dat-oversaet/k) er disse dokumenter samt en implementering af det udvidede Minimal givet. Denne implementation er (efter forfatterens bedste overbevisning) korrekt, men ikke specielt optimeret. Særligt interesserede kan finde en mere optimeret oversætter (som dog stadig har mulighed for utallige forbedringer) i filen Compiler1.sml. Optimeringerne ligger i behandlingen af betingelser, som er oversat som i figur 6.8 i Basics of Compiler Design med en forbedring svarende til opgave 6.9. For at bruge den optimerede oversætter, skal Compiler1.sml omdøbes til Compiler.sml, så den erstatter den simplere oversætter. 1

2 Man kan i karakteropgaven vælge enten at udvide en af ovennævnte implementeringer eller den implementering, som man har været med til at lave i forbindelse med godkendelsesopgaven. Under alle omstændigheder bør det klart fremgå af rapporten hvilken implementering, der bruges som udgangspunkt, og hvis egen gruppes implementering af G-opgaven bruges, skal der i rapporten være en reference til det katalog på DIKU s maskiner, hvor denne implementering findes. Hvis gruppen i fællesskab har rettet eller forbedret deres oversætter siden afleveringen af G-opgaven, bør dette detaljeres i rapporten, sådan at det klart fremgår, hvad udgangspunktet for den individuelle opgave er. Krav til besvarelsen. De i den valgte opgave beskrevne udvidelser skal implementeres og afprøves på de nævnte testprogrammer. Hvis udvidelserne beskriver regler og begrænsninger vedrørende typer eller lignende, skal typecheckeren checke, at disse er overholdt (medmindre andet er angivet). Opgavebesvarelsen skal indeholde en kort beskrivelse af de ændringer, der laves i komponenterne til oversætteren. For Parser.grm skal der kort forklares hvordan grammatikken er gjort entydig (ved omskrivning eller brug af operatorpræcedenserklæringer) samt beskrivelse af eventuelle ikke-åbenlyse løsninger, f.eks. i forbindelse med opbygning af abstrakt syntaks. Det skal bemærkes, at alle konflikter skal fjernes v.h.a. præcedenserklæringer eller omskrivning af syntaks. Med andre ord må MosML-yacc ikke rapportere konflikter i tabellen. For Type.sml og Compiler.sml skal kort beskrives, hvordan typerne checkes og kode genereres for de nye konstruktioner. Brug evt. en form, der ligner figur 5.2 og 6.3 i Basics of Compiler Design. Du skal ikke vedlægge udskrifter af hele programteksten, men du skal angive adressen på et filkatalog på DIKU s førstedelssystem, hvor alle relevante filer kan findes. Der må ikke efter afleveringsfristen rettes i filerne i dette katalog. Særligt vigtige mindre dele af programteksten kan inkorporeres som figurer i rapporten. Rapporten skal beskrive hvorvidt oversættelse og kørsel af eksempelprogrammer (jvf. afsnit 4) giver den forventede opførsel, samt beskrivelse af afvigelser derfra. Kendte mangler i typechecker og oversætter skal beskrives, og i det omfang det er muligt, skal der laves forslag til hvordan disse evt. kan udbedres. Der bliver ikke lagt ret stor vægt på effektiviteten af oversætteren (sålænge det ikke tager flere minutter at oversætte eksempelprogrammerne), så det anbefales at bruge simple datastrukturer. Desuden er det vigtigere at kunne køre alle eksempelprogrammerne end at generere effektiv kode kun for nogle af disse, så det anbefales at man ikke laver optimeringer før man har en fuldt fungerende oversætter. Man kan godt opnå god karakter uden at lave optimeringer, sålænge den grundlæggende implementering er fornuftig og velargumenteret. 2

3 Det er i stort omfang op til dig selv at bestemme, hvad du mener er væsentligt at medtage i rapporten, sålænge de eksplicitte krav i dette afsnit er opfyldt. Udover udskrifter må rapporten maksimalt fylde 10 sider, helst mindre, dog uden at udelade beskrivelser af mangler i programmet eller væsentlige designvalg. 2.1 Afgrænsninger af oversætteren Det er helt i orden, at lexer, parser og typechecker stopper ved den første fundne fejl. Hovedprogrammet MC.sml kører typecheck på programmerne inden oversætteren kaldes, så oversætteren kan antage, at programmerne er uden typefejl m.m. Det kan antages, at offsets og konstanter i Minimal-programmer er små nok til, at de kan være i konstantfelterne i MIPS instruktioner. Endvidere kan det antages at de oversatte programmer er små nok til, at alle hopadresser kan ligge i konstantfelterne i branch- og hopordrer. Der skal ikke laves test for overløb på stakken eller hoben. Den faktiske opførsel ved overløb er udefineret, så om der sker fejl under afvikling eller oversættelse, eller om der bare beregnes mærkelige værdier, er underordnet. Stak og hob skal dog være store nok til, at testprogrammerne kan køre uden overløb med de angivne testdata. 3 De enkelte opgaver I de følgende afsnit er fem forskellige opgaver omkring udvidelser af sproget Minimal angivet. Du skal vælge en af disse, og du må ikke vælge samme udvidelse som et andet medlem af den gruppe, som du lavede godkendelsesopgaven sammen med. Det er op til gruppemedlemmerne at blive indbyrdes enige om en fordeling af opgaverne. Opgaverne er søgt lavet, så de er nogenlunde lige omfattende, men nogle kan have mere vægt på typecheck end på kodegenerering eller omvendt. Ingen af opgaverne er trivielle, men der er heller ingen skjulte fælder, der gør opgaverne betydeligt vanskeligere, end de ser ud. 3.1 Opgave 1: Tildelinger og løkker Syntaksen af Minimal som beskrevet i Sproget Minimal og Udvidelser til Minimal udvides med følgende produktioner: TypeId void id Exp Exp ; Exp Exp id := Exp Exp loop Exp Exp break 3

4 Semikolon (;) binder svagere end := og loop, som begge har samme præcedens som =>, else, in og write. Det kan ikke observeres om semikolon er højre- eller venstreassociativ, så du må selv vælge Semantik Typen void bruges til udtryk, der ikke beregner en værdi, men i stedet udføres for deres sideeffekt. Variabler (både parametre til funktioner og letbundne variabler) kan ikke have typen void, men funktioner kan godt have resultattype void. Udtrykket e 1 ;e 2 udregnes ved først at udregne e 1 og derefter e 2. Det er typen og værdien af e 2, der bruges som type og værdi for hele udtrykket e 1 ;e 2. e 1 skal have typen void. Udtrykket x:=e udregner e til en værdi v og overskriver derefter indholdet af variablen x med v. Den nye værdi for x er gyldig i resten af x s virkelfelt eller indtil næste tildeling til x (hvad, der end sker først). x og e skal have samme type, men denne kan ellers være vilkårlig (dog ikke void). Hele udtrykket har typen void. Udtrykket loop e 1 er en løkke, der gentager udregning af e 1 indtil løkken forlades med et break udtryk. e 1 skal have typen void, og hele løkken (loop e 1 ) har også typen void. Et udtryk af formen break vil forlade den nærmest omgivende løkke. break har typen void. Der kan godt være mere end et break-udtryk inde i en løkke. break-udtryk skal stå inde i løkker, så der skal gives en fejlmeddelelse, hvis break forekommer udenfor en løkke Testprogrammer Testprogrammer til denne udvidelse har navne, der begynder med loop, f.eks. loop-primes.m og loop-error01.m. Se endvidere afsnit Opgave 2: Generelle lister og par Minimal udvides med partyper (svarende til SML s partyper) og med lister, hvor elementerne kan være af vilkårlig (men konsistent) type. Syntaksen af Minimal som beskrevet i Sproget Minimal og Udvidelser til Minimal ændres som følgende: Produktionerne for TypeId erstattes af følgende: 4

5 TypeId Type id Type int Type bool Type Type list Type Type Type ( Type ) Der tilføjes ekstra produktioner for Exp: Exp Exp Exp let id = Exp in Exp Exp ( Type ) [] er højreassociativ og binder stærkere end ::, men svagere end +. I typer stærkere end list. Symbolerne ( og ) bruges til at gruppere typeudtryk (ligesom almindelige parenteser bruges i regneudtryk). NB! Den trykte udgave af K-opgaven bruger fejlagtigt almindelige parenteser til gruppering af typeudtryk. Dette er en fejl, da det giver en parserkonflikt, der er meget svær at fjerne Semantik Et udtryk af formen e 2 vil først beregne e 1 og e 2 til værdierne v 1 og v 2. Derefter allokeres to sammenhængende maskinord i hoben, v 1 lægges ind i det første og v 2 lægges ind i det andet. Værdien af udtrykket e 2 er adressen på det første af de to maskinord. Hvis e 1 og e 2 har typerne t 1 og t 2 vil e 2 have typen t 2. Et udtryk af formen let y = e 1 in e 2 vil først udregne e 1 (som skal have en type af formen t 2 ) til adressen på to sammenhængende maskinord. Indholdet af det første af de to maskinord lægges ind i variablen x og indholdet af det andet maskinord lægges ind i variablen y. Virkefeltet af x og y er e 2, som beregnes til at give værdien af hele let-udtrykket. x har typen t 1, y har typen t 2 og hele udtrykket har samme type som e 2 (som kan være vilkårlig). NB! De to variabler x og y skal være forskellige (dette krav er ikke angivet i den trykte opgavetekst). Listeelementer kan nu være af vilkårlige typer inklusive par- og listetyper, så det er f.eks. muligt at have en liste af lister af heltal eller en liste af par af heltal og boolske værdier. Par kan også bygges af vilkårlige typer, f.eks. kan man have et par bestående af et heltal og en liste af boolske værdier. Under typecheck skal der tages særligt hensyn til den tomme liste ([]), da man ikke kan se til hvilken listetype den tomme liste hører. [] kan f.eks. betyde både den tomme liste af heltal, den tomme liste af par af heltal osv. For at gøre dette entydigt, indføres konstruktionen (t)[], hvor t er en type. Det betyder at [] her har typen t (som følgelig skal være en listetype). [] kan af hensyn til bagudkompatibilitet stadig bruges uden typeangivelse. I givet fald har [] (som i det oprindelige sprog) typen int list. 5

6 3.2.2 Testprogrammer Testprogrammer til denne udvidelse har navne, der begynder med types, f.eks. types-primes.m og types-error01.m. Se endvidere afsnit Opgave 3: Udvidede case-udtryk Minimal udvides med generaliserede case-udtryk. Syntaksen af Minimal som beskrevet i Sproget Minimal og Udvidelser til Minimal ændres som følgende: Produktionen for case-udtryk erstattes med følgende: Exp case Exp of Rules hvor Rules er beskrevet med produktionerne Rules Rule Rules Rules Rules Rule Pattern => Exp Pattern id Pattern num Pattern true Pattern false Pattern [] Pattern Pattern :: Pattern Ovenstående grammatik har en tvetydighed omkring indlejredede case-udtryk. Eksempel: I følgende programstump kan den sidste regel ( v::w => 2) binde til begge case-udtryk. case x of [] => 0 y::z => case z of [] => 1 v::w => 2 Problemet er velkendt fra SML og løses på samme måde: Hvis der er flere indlejrede case-udtryk, binder regler til den nærmeste case. I eksemplet binder den sidste regel altså til det andet case-udtryk. Tvetydigheden kan løses med præcedensregler eller omskrivning af grammatikken. 6

7 3.3.1 Semantik Hvert case-udtryk består af et udtryk e 0 og en række regler (rules), som hver består af et mønster (pattern) og et udtryk. Semantikken er, at e 0 udregnes til en værdi v, hvorefter hver regel prøves i rækkefølge, indtil man finder en regel, hvis mønster matcher v, hvorefter reglens udtryk beregnes i omgivelser, hvor variabler i mønstret er bundet til de tilsvarende dele af værdien. Variablerne i mønstret har med andre ord virkefelt i udtrykket i den regel, hvor mønstret indgår. Det kan antages, at reglerne er udtømmende, dvs. at der til enhver værdi findes mindst en regel, der matcher værdien. Dette behøves ikke at blive testet, og skulle en værdi ikke matche nogen regel, er det udefineret, hvad der sker. Alle udtrykkene i reglerne skal have ens type (som ellers kan være vilkårlig), og denne type er resultattype af hele case-udtrykket. Alle reglernes mønstre skal være kompatible med typen af e 0. Her bruges følgende regler: Et variabelmønster er kompatibel med enhver type. Et talmønster er kompatibel med typen int. Mønstrene true og false er kompatible med typen bool. Mønstret [] er kompatibel med typen int list. Et mønster af formen p 1 :: p 2 er kompatibel med typen int list, forudsat at p 1 er kompatibel med typen int og p 2 er kompatibel med typen int list. p 1 og p 2 må ikke indeholde variabler af samme navn. Med andre ord må et mønster ikke indeholde gentagne variabler (dette skal checkes af typecheckeren). Et mønster matcher værdier og binder variabler efter følgende regler: Et variabelmønster matcher enhver værdi, og binder variablen til denne værdi. Et talmønster n matcher en talværdi m, hvis m = n. Der bindes ingen variabler. Mønstret true matcher den sande boolske værdi. Der bindes ingen variabler. Mønstret false matcher den falske boolske værdi. Der bindes ingen variabler. Mønstret [] matcher den tomme liste. Der bindes ingen variabler. Et mønster af formen p 1 :: p 2 matcher en ikke-tom liste l, forudsat at p 1 matcher hovedet af l og p 2 matcher halen af l. 7

8 Hvis et mønster ikke matcher værdien, prøves næste regel. Det kan antages, at den sidste regel matcher, hvis ingen af de foregående gør det. Vink: Man kan ved oversættelse af mønstre med fordel bruge en label som nedarvet attribut: Når mønstret ikke matcher, hoppes til denne label. Koden, der skal udføres ved succesfuld match, kan ligge lige efter koden for mønstret, så der ikke laves noget hop, når mønstret matcher Testprogrammer Testprogrammer til denne udvidelse har navne, der begynder med case, f.eks. case-primes.m og case-error01.m. Se endvidere afsnit Opgave 4: Records Syntaksen af Minimal som beskrevet i Sproget Minimal og Udvidelser til Minimal ændres ved at tilføje følgende produktioner: Prog Exp where RecordDecls Funs RecordDecls record { TypeIds } id RecordDecls RecordDecls RecordDecls TypeId record id id Exp FieldId Exp id { FieldDefs } FieldId id FieldId FieldId. id FieldDefs FieldDef FieldDefs FieldDef, FieldDefs FieldDef id = Exp Produktionen Exp id fjernes til gengæld fra grammatikken, da almindelige variabler er indeholdt i produktionerne for FieldId.. er en operator, så der kan være mellemrum (whitespace) før eller efter denne.. binder stærkere end alle andre operatorer Semantik En record er en hoballokeret datastruktur, som har et antal navngivne felter, som hver er tilknyttet en værdi. Recordtyper skal erklæres med record-erklæringer. En record-erklæring opremser (i krølleklammer) felternes navne og typer og angiver tilsidst navnet på recordtypen. Virkefeltet af en record-erklæring er de efterfølgende record-erklæringer og funktioner samt udtrykket før where. En record må ikke indeholde to eller flere felter med samme navn og to recordtyper må ikke dele feltnavne. Med andre ord må hvert feltnavn kun forekomme 8

9 en gang i en record-erklæring. Et felt i en record kan have enhver type, inklusive lister eller andre recordtyper. Hvis et felt har en recordtype, skal denne recordtype være erklæret i en tidligere record-erklæring. Der er derfor ikke mulighed for (direkte eller indirekte) rekursive recordtyper. Der må ikke være to recordtyper af samme navn. Variabler eller felter af recordtype erklæres ved at angive nøgleordet record og recordtypenavnet før variabelnavnet. En record bygges ved først at angive recordtypenavnet og derefter (i krølleklammer) at give felterne værdier. Rækkefølgen af felter skal være den samme som i erklæringen, og alle felter skal gives værdier af deres erklærede typer. Eksempel: Givet erklæringerne record {int x, int y} point record {int radius, record point centre} circle vil udtrykket circle{radius = 5, centre = point{y = 17, x = 12}} have typen record circle. Hvis variablen x er en recordvariabel, som indeholder et felt med navn f, så vil udtrykket x.f returnere værdien af feltet f i x. Gentagen brug af. giver adgang til felter i indlejrede records. Hvis f.eks. y har værdien fra eksemplet herover, så vil y.centre have værdien svarende til udtrykket point{x = 12, y = 17} og y.centre.y vil have værdien 17. Læg mærke til, at den første forekomst af y er et variabelnavn, mens den anden forekomst er et feltnavn. Records bliver som nævnt allokeret på hoben (ligesom lister). En værdi af recordtype implementeres som en pointer til den hoballokerede record. I eksemplet ovenfor er y således en pointer til en record, der består af to maskinord indeholdende henholdsvis et heltal 5 og en pointer til en anden hoballokeret record, som også består af to maskinord, denne gang med værdierne 12 og 17. Vink: Lav en særskilt symboltabel for recordtyper og evt. også en for feltnavne Testprogrammer Testprogrammer til denne udvidelse har navne, der begynder med record, f.eks. record-qsort.m og record-error01.m. Se endvidere afsnit Opgave 5: Arrays Minimal udvides med hoballokerede tabeller (arrays) med elementer af vilkårlig type (inklusive andre tabeltyper). Syntaksen af Minimal som beskrevet i Sproget Minimal og Udvidelser til Minimal ændres som følgende: Produktionerne for TypeId erstattes af følgende: 9

10 TypeId Type id Type int Type bool Type int list Type Type array Der tilføjes ekstra produktioner for Exp: Exp alloc Exp of Exp Exp size Exp Exp Exp [ Exp ] Exp Exp [ Exp ] := Exp of, size og tildelingsoperatoren := har samme præcedens som write, else, => osv. Tabelopslag (med [ og ]) binder stærkere end alle operatorer Semantik En tabel med elementer af typen t har typen t array. En værdi af typen t array er adressen på et stykke hoballokeret lager, der indeholder tabellens størrelse og dens elementer, som er af type t. Man allokerer en tabel på hoben med alloc e 1 of e 2, hvor e 1 beregnes til et heltal n og e 2 til en værdi v af type t, hvorefter der allokeres n+1 sammenhængende maskinord på hoben. Det første af disse sættes til at indeholde n, mens alle de resterende n maskinord sættes til v. Udtrykket alloc e 1 of e 2 vil returnere adressen på det andet af de allokerede maskinord, det vise sige adressen på første element i tabellen. Den returnerede tabel har typen t array. Man kan godt allokere en tabel med 0 elementer. I givet fald allokeres kun et maskinord, der indeholder størrelsen (altså 0). Bemærk, at e 2 beregnes een gang uanset hvor mange elementer, der allokeres (selv 0). Det er udefineret, hvad der sker, hvis man forsøger at allokere et negativt antal elementer (altså hvis n < 0). size e beregner e til tabel (dvs. en adresse a) og returnerer tabellens størrelse (dvs. indholdet af maskinordet på adressen a 4). Hvis e 1 er et udtryk af typen t array og e 2 er et udtryk af typen int, vil udtrykket e 1 [e 2 ] først beregne e 1 til en adresse a og e 2 til et heltal n og dernæst returnere indholdet af maskinordet på adressen a + 4n (dvs. det n te element i tabellen, hvor det første element har nummer 0). Typen af resultatet er t. Hvis der ikke er noget element med nummer n i tabellen, dvs. hvis n < 0 eller n m, hvor m er antallet af elementer i tabellen, skal programmet stoppe og indikere fejlen ved at udskrive tallet Hvis e 1 er et udtryk af typen t array, e 2 er et udtryk af typen int og e 3 et udtryk af type t, vil udtrykket e 1 [e 2 ] := e 3 være af typen t. Først beregnes e 1 til 10

11 en adresse a og e 2 til et heltal n og dernæst beregnes e 3 til en værdi v af type t, som lægges i maskinordet på adressen a + 4n. Resultatet af hele udtrykket er v. Igen skal programmet stoppe og udskrive -777, hvis n ikke ligger indenfor tabellens grænser Testprogrammer Testprogrammer til denne udvidelse har navne, der begynder med array, f.eks. array-primes.m og array-error01.m. Se endvidere afsnit 4. 4 Eksempelprogrammer I kataloget /usr/local/del1/dat-oversaet/k findes testprogrammer for hver af ovenstående opgaver. De til den valgte opgave hørende eksempelprogrammer skal oversættes og køres på inddata, der for program.m er givet i filen program.in (hvis ikke der er en sådan fil, køres programmet uden inddata). Uddata fra kørslen af et program skal stemme overens med det, der er givet i filen program.out. Filer, hvis navn indeholder teksten error (f.eks. loop-error01.m) indeholder typefejl, og oversættelse af disse skal given en relevant fejlmeddelelse og angivelse af omtrentlig position i programmet. Udover testprogrammerne til den valgte opgave, skal man stadig kunne afvikle eksempelprogrammerne fra godkendelsesopgaven og rapportere fejl for de fejlbehæftede programmer. Dog kan visse af de programmer, der i godkendelsesopgaven skulle give typefejl, som følge af udvidelserne af sproget nu være typekorrekte, og disse skal derfor ikke give typefejl. Det bør nævnes i rapporten, hvor dette er tilfældet. Det er ikke noget krav, at der testes med flere testprogrammer end de ovenstående, men hvis man f.eks. laver optimeringer, kan det være en god ide at lave programmer, der afprøver disse. Selv om registerallokatoren ikke laver spill, er der rigeligt med registre til, at eksempelprogrammerne kan oversættes uden spill. Derfor betragtes det som en fejl, hvis registerallokatoren rejser undtagelsen not_colourable for et af eksempelprogrammerne. /usr/local/del1/dat-oversaet/k indeholder også opgaveteksten (dette dokument) og filen G-sol.zip. Indholdet af /usr/local/del1/dat-oversaet/k findes også i filen K.zip via kursets hjemmeside (fra siden om rapportopgaver). 11