Implementace interpretu imperativního jazyka IFJ12

Transkript

1 Dokumetace k projektu do předmětů IFJ a IAL Implementace interpretu imperativního jazyka IFJ12 Tým 78, varianta b/3/ii 9. prosince 2012 Seznam autorů: Blanárik, Martin xblana00@stud.fit.vutbr.cz 20% Čulen, Jozef xculen01@stud.fit.vutbr.cz 20% Kadlec, Peter xkadle30@stud.fit.vutbr.cz 20% Přikryl, Vojtěch xprikr28@stud.fit.vutbr.cz 20% Šoková, Veronika xsokov00@stud.fit.vutbr.cz 20% Seznam rozšíření: BYTECODE

2 Obsah 1 Úvod 3 2 Zadání a návrh implementace 4 3 Implementace Správa paměti Lexikální analyzátor Syntaxí řízený překlad Syntaktický analyzátor Statický sémantický analyzátor Generování vnitřního kódu Interpret Implementované algoritmy Hashovací tabulka Shell sort Boyer-Mooreův algoritmus Testování Rozšíření BYTECODE Práce v týmu Schůzky a komunikace v rámci týmu Rozdělení úkolů Správa zdrojového kódu Závěr Metriky kódu A Konečný automat pro implementaci lexikálního analyzátoru 11 B LL-gramatika 12 C Precedenční tabulka 13 D Instrukční sada 14 2

3 1. Úvod Tato dokumentace popisuje vývoj a implementaci interpretu imperativního jazyka IFJ12. Úlohou tohoto interpretu je kontrola vstupního zdrojového kódu a jeho interpretaci v případě, že je v pořádku. V opačném případě pak program informuje o typu chyby. Dokumentace je logicky členěna na kapitoly a postupně popisuje jednotlivé komponenty interpretu, způsob jejich implementace a společnou provázanost tvořící fungující celek. Také jsou rozebrány nejvýznamnější algoritmy, použité při implementaci. Také je zmíněn způsob práce v rámci týmu a problémy s tím spojené. V závěru dokumentace je shrnutí naší práce a hodnocení a přínos celého projektu. Také jsou přiloženy přílohy, popisující teoretický podklad pro implementaci zásadních prvků interpretu. 3

4 2. Zadání a návrh implementace Jazyk IFJ12 je podmnožinou jazyka Falcon 1, který patří mezi open-source skriptovací jazyky. IFJ12 je case-sensitive (rozlišují se malá/velká písmena) a je jazykem dynamicky typovaným (datový typ proměnné se určí na základě hodnoty do ní vložené). Naším úkolem bylo pro tento jazyk naprogramovat interpret a to v jazyku C. Při analýze problému implementace interpretu jsme tento problém rozdělili na několik dílčích částí: 1. Lexikální analyzátor 2. Syntaxí řízený překlad (a) Syntaktický analyzátor (b) Sémantický analyzátor 3. Interpret 4. Vestavěné funkce interpretu 5. Testování Toto rozčlenění nám umožnilo rozdělit úkoly mezi jednotlivé členy týmu a tím pádem pracovat paralelně a částečně nezávisle na ostatních. Více o tomto rozdělení a celkové týmové práci v kapitole 4. 1 Oficiální webové stránky: 4

5 3. Implementace V této kapitole popíšeme způsob implementace jednotlivých části interpretu. 3.1 Správa paměti Při prvotních návrzích implementace jednotlivých částí interpretu jsme narazili na celkem nepříjemnou věc - práce s dynamicky alokovanou pamětí. S tím spojené problémy jsou zejména častá nutnost ověření, jestli se alokace zdařila a dále uvolnění veškeré paměti v případě predčasného ukončení překladu. Pro vyhnutí se těmto problémům jsme implementovali jednoduchý správce paměti nazvaný Garbage Collector. Je navržen tak, aby při každém pokusu o alokování nebo realokování paměti nejdříve ošetřil úspěšné provedení dané operace a následně si uložil ukazatel na pamět právě alokovanou. Tím pádem je již velice jednoduché kdykoliv uvolnit veškerou aktuálně používanou pamět. Garbage Collector byl implementován v souboru gc.c pomoci lineárně zřetězeného seznamu a poskytuje funkce GCMalloc, GCRealloc, GCFree a GCClearAll. První tři funkce se navenek chovají identicky vůči knihovním funkcím malloc, realloc a free. Funkce GCClearAll pak uvolní najednou veškerou používanou pamět a připraví tak program k ukončení. 3.2 Lexikální analyzátor Úloha lexikálního analyzátoru spočívá v načítání vstupního zdrojového kódu jazyka IFJ12 a jeho rozdělení na jednotlivé lexémy. Spravně načtené lexémy pak vrací jako tokeny. Lexikální analyzátor jsme realizovali jako 29-stavový konečný automat (jeho grafický model lze nalézt v příloze A). Tokeny, které lexikální analyzátor vrací funkcí getnexttoken, jsou řešeny pomocí abstraktní datové struktury, která obsahuje informace o typu lexému, řádek na kterém se nachází a pro některé typy lexému i jeho obsah (např. string). Implementace byla přímočará a obešla se bez větších komplikací. Jedna komplikace nastala při více po sobě následujících EOL 1. V tomto případě bylo třeba přeskočit až na poslední z nich a vrátit jen ten (původně navrhovný automat toto neumožňoval). 3.3 Syntaxí řízený překlad Syntaxí řízený překlad řídí chod interpretu. Skládá se ze dvou částí. Modul parser.c je založený na metodě rekurzivního sestupu podle LL(1)-gramatiky (viz příloha B) a řeší analýzu bez výrazů. Modul expr parser.c je založený na precedenční syntaktické analýze a je volaný parserem pro výrazy. Současně probíhá jak syntaktická, tak i statická sémantická kontrola a generování vnitřního kódu. 1 EOL = end of line = konec řádku 5

6 3.3.1 Syntaktický analyzátor Pomocí LL-tabulky jsou implementované funkce příslušné jednotlivým nonterminálům. Terminály zpracovává funkce expect, která porovná aktuálně načtený token s očekávaným a od lexikální analýzy si vyžádá další. Pokud se nezhodují, je program ukončen syntaktickou chybou. Pokud syntaktický analyzátor narazí na výraz, volá modul expr parser.c. Ten postupně načíta všechny tokeny obsažené ve výrazu, kontroluje jejich výskyt v tabulce symbolů a zároveň doplňuje tabulku konstant. Pro práci s načítaným výrazem využívá precedenční tabulku (viz příloha C). Začátek kontroly nastává při zavolání funkce prog Statický sémantický analyzátor Pro potřeby sémantické analýzy byla navrhnuta tabulka symbolů implementovaná jako tabulka s rozptýlenými položkami (podrobněji popsána v kapitole 3.5.1). Do něj jsou vkládaná id proměnných a funkcí. Konstanty se ukládají zvlášt do tabulky, která je řešena jako pole unionů. Jelikož jazyk IFJ12 povoluje volání uživatelem vytvořené funkce dříve než byla definována, bylo potřeba zabezpečit zpětnou kontrolu. Ta se vykoná po proběhnutí celé analýzy voláním funkce funcisdef nad 0. úrovní tabulky Generování vnitřního kódu Vnitřní kód se skládá z jednoduchých instrukcí založených na indexaci, které generuje funkce geninstruction. Tento postup jsme zvolili, aby výsledný výstup nebyl závislý na adrese operandu v případě rekurzivního volání funkce. Jelikož jazyk umožňuje definovat funkce přímo mezi příkazy hlavního programu, bylo nutno zavést 2 instrukční pásky, které se podle kontextu střídají. Byly implementovány jako pole. Indexy na dosud nedefinované funkce se ukládají na zásobník, který je řešený lineárně zřetězeným seznamem. 3.4 Interpret V této části již probíhá samotná interpretace kódu z instrukční pásky (instrukční sadu lze nalézt v příloze D. Nejdříve se zpracují operandy pomocí funkce getop, která vrátí dle zadaného indexu správný ukazatel na položku z pole unionů. Pro nezáporný index vrací ukazatel do tabulky konstant, pro záporný pak ukazatel do zásobníku. Volání podporgramů je řešené již zmiňovaným zásobníkem, návratové hodnoty se ukládají do pomocné proměnné retval. Řídící instrukce, aritmetické a relační operace jsou řešené v rámci samostatného modulu interpret.c a pro vestavěné funkce se předává řízení modulu builtin.c. Při interpretaci se zároveň vykonává dynamická sémantická kontrola nad typy operandů a ošetřuje se dělení nulou. 3.5 Implementované algoritmy V rámci implementace interpretu jsme použili některé významené algoritmy. Při realizaci těchto algoritmů jsme využili znalosti získané z předmětu IAL. 6

7 3.5.1 Hashovací tabulka Podle varianty zadání jsme měli tabulku symbolů implementovat jako hashovací tabulku. Zvolili jsme typ jednoúrovňové blokově strukturované tabulky 2. Důvod tohoto výběru je ten, že vyhledávání probíhá paralelně nad všemi úrovněmi a to nám zaručilo, že identifikátor proměnné nebude současně identifikátorem funkce a naopak. Při použití jazyka IFJ12 může nastat maximálně dvojnásobné zanoření, přičemž se vždy vytváří úroveň 0 pro globální id funkcí a úroveň 1 pro hlavní program. Pokud zpracováváme tělo funkce, otevře se 2. úroveň (funkce openscope) a proměnné 1. úrovně jsou skryté. Při následném uzavření této úrovně (funkce closescope) se obnoví 1. úroveň, symboly se smažou a obnoví se skryté položky. Při vkládání identifikátoru pomocí funkce htable lookup se vytvoří (popř. upraví) položka hashovací tabulky s klíčem a nastaví se ukazatel na konkrétní symbol. Pokud nastane kolize, vytvoří se lineárně zřetězený seznam položek, ve kterém se vyhledává lineárně. Vrací se ukazatel na příslušný symbol, nebo NULL (v případě, že nastala kolize mezi id funkce a lokální proměnnou a jedná se tedy o sémantickou chybu). Nové klíče jsou vkládané do vytvořeného řetězce příslušnému aktuální úrovni, aby nedocházelo k časté alokaci paměti. V tabulce se pak uchovávají jen adresy Shell sort Vestavěnou funkci sort jsme dle naší varianty zadání měli implementovat pomocí řadícího algoritmu Shell sort. Tento řadící algoritmus je podobný Insert sortu, nicméně využívá tzv. snižující se přírustek. Algoritmus tedy neřadí prvky, které jsou výhradně vedle sebe, ale i takové, mezi kterými je určitá mezera (až polovina velikosti seřazovaného pole). V každém kroku je tato mezera zmenšena. Díky tomu je možno řadit prvky, které jsou dále od sebe a tím pádem jsou prvky vysokých a nízkých hodnot rychle přemístěny na správnou stranu pole. Pro dosažení co nejlepší časové složitosti je zásadní, jakým způsobem zmenšujeme mezeru. Empiricky byl nalezen optimální způsob - dělení konstantou Pro tuto hodnotu pak algoritmus dosahuje časové složitosti O(n 3 2 ). Tento řadící algoritmus je tedy pomalejší, než ty nejvýkonnější (QuickSort, HeapSort,...) a také je nutno podotknout, že je nestabilní 4, což ale v našem případě není podstatné Boyer-Mooreův algoritmus Vestavěnou funkci find jsme implementovali na základě Boyer-Mooreova algoritmu. Tento algoritmus je velmi rozšířeným způsobem hledání podřetězce v řetězci. Nabízí několik typů heuristiky, díky nimž je možno při porovnávání přeskakovat velké množství znaků a tím tedy algoritmus značně zrychlit. My jsme použili tzv. bad-character heuristiku Testování Testování je při vývoji softwaru velmi podstatné, proto jsme se snažili jej nepodcenit. Každá dílčí část interpretu byla proto důsledně otestována, aby se chyby odhalily již na nízké úrovni a bylo jednodušší je správně detekovat a odstranit. Výsledný program byl pak 2 Zdroj: (str ) 3 Zdroj: 4 Tzn. nezachovává původní pořadí dvou prvků se stejným klíčem 5 Studijní metariál: 7

8 komplexně testován na různých příkladech kódu jazyka IFJ12, které byly koncipovány tak, aby odhalily co možná největší množství možných chyb a pokryly i různé speciální situace (např. prázdný zdrojový soubor, práce s řetězci nulové délky, použití nepřímé rekurze, atd.). 3.7 Rozšíření Nad rámec zadání jsme se rozhodli implementovat jedno rozšíření BYTECODE Program generuje binární výstup bez interpretace, který je možno později interpretovat již bez potřeby načtení původního vstupu. Binární výstup má následující formát: "IFJ12"<ws 6 >+ <pocet instrukci> <ws>+ <pocet dat> <ws>+ <pocatecni ip> <ws> <instrukcie> <data> 6 ws = white-space = bílý znak 8

9 4. Práce v týmu 4.1 Schůzky a komunikace v rámci týmu Během práce na projektu se uskutečnily celkem 4 schůzky celého týmu. Obsahem byla celková strategie pro řešení projektu, návrh datových struktur pro snadnou komunikaci mezi jednotlivými částmi interpretu a řešení některých problémů a nejasností. Délka schůzky byla průměrně asi 40 minut. Jako hlavní komunikační prostředek na dálku jsme zvolili Facebook - zde jsme vytvořili skupinu pro náš projekt a zároveň používali vestavěný chat systém pro rychlou komunikaci. 4.2 Rozdělení úkolů K prvotnímu rozdělení úkolů došlo poměrně brzy a to následovně: Blanárik, Martin Čulen, Jozef Kadlec, Peter Přikryl, Vojtěch Šoková, Veronika Syntaktická analýza pro výrazy Lexikální analýza Interpret Správa paměti, vestavěné funkce Syntaktická analýza bez výrazů, generování instrukcí Toto rozdělení se postupem času ještě upřesňovalo a v ojedinělých případech se některé úkoly přerozdělovali. Na jednotlivé úkoly nebyly stanoveny nějaké deadliny. S tímto přístupem nebyly nějaké značné problémy, protože přístup všech členů týmu byl v rámci možností svědomitý. 4.3 Správa zdrojového kódu Důležitým aspektem pro vývoj týmového projektu je bezesporu sdílení zdrojového kódu. K tomu jsme využili systém SVN, který byl hostován na školním serveru Merlin. Zde byly sdíleny jak všechny zdrojové kódy týkající se projektu, tak i nějaké další informace, teoretické podklady a zápisy ze schůzek. Počet revizí nakonec přesáhl hodnotu 200. S použitím tohoto systému nebyly výrazné problémy ani u členů týmu, kteří s podobným systémem pracovali poprvé. Praktické zkušenosti s tímto systémem vnímali všichni vesměs pozitivně. 9

10 5. Závěr Práce na projektu nám přinesla určitě hodně zkušeností. Jak z pohledu implementačních dovedností v programovacím jazyku C, tak i z hlediska vývoje aplikace v týmu. V průběhu práce nebyly v týmu žádné problémy s komunikací a na většině rozhodnutí jsme se jednomyslně shodli. Problémy, se kterými jsme se potýkali, tak byly vesměs technického rázu. Někteří členové měli výrázné problémy s implementací některých svých úkolů a tyto problémy musely být následně řešeny přerozdělením úkolů. Nakonec jsme se však shodli na rovnoměrném rozdělení bodů. Výsledný interpret pracuje dle zadání a je obohacen o rozšíření BYTECODE. Jelikož byl vyvíjen v normě ISO C99, měl by být plně přenosný. Byl testovaný na 32- i 64- bitové architektuře na systémech GNU/Linux (Ubuntu), Unix (CentOS), BSD (FreeBSD) a Microsoft Windows Metriky kódu Počet souborů: 25 Počet řádků zdrojového textu: 5026 Velikost statických dat: 1080 B Velikost spustitelného souboru: B (systém Linux, 32-bitová architektura, bez ladících informací) 10

11 A. Konečný automat pro implementaci lexikálního analyzátoru 11

12 B. LL-gramatika 1. <prog> <telo> eof 2. <telo> ɛ 3. <telo> <func> <telo> 4. <telo> <p> <telo> 5. <prikazy> <p> <prikazy> 6. <prikazy> ɛ 7. <func> function id func ( <param> ) eol <prikazy> end eol 8. <param> ɛ 9. <param> id <n param> 10. <n param>, id <n param> 11. <n param> ɛ 12. <prirad> id = 13. <p> <prirad> <zvysok> 14. <zvysok> vyraz eol 15. <zvysok> <str term> [ <num term> : <num term> ] eol 16. <str term> string 17. <str term> id 18. <num term> ɛ 19. <num term> numeric 20. <num term> id 21. <p> if vyraz eol <prikazy> else eol <prikazy> end eol 22. <p> while vyraz eol <prikazy> end eol 23. <zvysok> id func ( <term> ) eol 24. <term> ɛ 25. <term> <typ term> <n term> 26. <n term>, <typ term> <n term> 27. <n term> ɛ 28. <typ term> numeric 29. <typ term> nil 30. <typ term> boolean 31. <typ term> <str term> 32. <p> return vyraz eol 12

13 C. Precedenční tabulka + - * / ** < > <= >=!= == ( ) ID ID FUNC, $ NUM STRING BOOL NIL + > > < < < > > > > > > < > < < > > < < < < - > > < < < > > > > > > < > < < > > < Ss Ss < * > > > > < > > > > > > < > < < > > < < Ss < / > > > > < > > > > > > < > < < > > < Ss Ss < ** > > > > > > > > > > > < > < < > > < Ss Ss < < < < < < < > > > > > > < > < < > > < < < < > < < < < < > > > > > > < > < < > > < < < < <= < < < < < > > > > > > < > < < > > < < < < >= < < < < < > > > > > > < > < < > > < < < <!= < < < < < > > > > > > < > < < > > < < < < == < < < < < > > > > > > < > < < > > < < < < ( < < < < < < < < < < < < = < < = Sx < < < < ) > > > > > > > > > > > Sx > Sx Sx > > Sx Sx Sx Sx ID > > > > > > > > > > > Sx > Sx Sx > > Sx Sx Sx Sx ID FUNC Sx Sx Sx Sx Sx Sx Sx Sx Sx Sx Sx = Sx Sx Sx Sx Sx Sx Sx Sx Sx, < < < < < < < < < < < < = < < = Sx < < < < $ < < < < < < < < < < < < Sx < < Sx Sx < < < < NUM > > > > > > > > > > > Sx > Sx Sx > > Sx Sx Sx Sx STRING > Ss > Ss Ss > > > > > > Sx > Sx Sx > > Sx Sx Sx Sx BOOL Ss Ss Ss Ss Ss > > > > > > Sx > Sx Sx > > Sx Sx Sx Sx NIL > > > > > > > > > > > Sx > Sx Sx > > Sx Sx Sx Sx $ - začátek a konec výrazu Sx - Syntaktická chyba Ss - Sémantická chyba 13

14 D. Instrukční sada legenda: ip proměnná: -1..-n (zásobník) ik konstanta: 0..n (tabulka konstant) ii instrukce: 0..n (instrukční páska) T typ pro pole unionů P počet - NIL kód operandy popis I NOP -,-,- prázdná operace I EXIT -,-,- konec programu I LAB -,-,- návěští vestavěné funce: I INPUT -,-,ip načítání znaků ze standardního vstupu I NUM ip/ik,-,ip vrátí číslo vzniklé převodem termu typu řetězec nebo číslo I TYPE ip/ik,-,ip vrátí typ proměnné nebo termu I LEN ip/ik,-,ip vrátí délku řetězce I FIND ip/ik,ip/ik,ip hledá 1. výskyt podřetězce v zadaném řetězci a vrátí jeho pozici I SORT ip/ik,-,ip seřadí znaky v řetězci tak, aby ordinálně nižší znak byl před vyšším I PRINT P,-,iP vypíše hodnoty termu (P = počet parametrů předaných na zásobník) I SUBSTR1 ip/ik,-,- výběr podřetězce (načítá řetězec) I SUBSTR2 ip/ik,ip/ik,ip výběr podřetězce (pozicie od, pozice do, výsledek) řídíci instrukce: I PUSH ip/ik,t,- vložení na zásobník I PUSHN -,P,- vloží na zásobník P-počet NILů I MOV ik,t,ip přesun hodnoty I CALL P,P,iI volání funkce (počet parametrů, počet lok. proměnných, návěští funkce) I RET -,T,iP návrat z funkce (ip = návratová hodnota) I JMP ip/ik,-,ii podmíněný skok aritmetické instrukce: I ADD ip/ik,ip/ik,ip a + b I SUB ip/ik,ip/ik,ip a b I MUL ip/ik,ip/ik,ip a b I DIV ip/ik,ip/ik,ip a/b I POW ip/ik,ip/ik,ip a b I POWSTR ip/ik,ip/ik,ip mocnina řetězce I CONCAT ip/ik,ip/ik,ip konkatenance řetězce relační instrukce: I CMP ip/ik,ip/ik,ip a = b I EXCLEQ ip/ik,ip/ik,ip a b I LOWER ip/ik,ip/ik,ip a < b I HIGHER ip/ik,ip/ik,ip a > b I LOWEREQ ip/ik,ip/ik,ip a b I HIGHEREQ ip/ik,ip/ik,ip a b I PLUS ip/ik,ip/ik,ip rozhoduje, jestli použít I ADD nebo I CONCAT I ASTERISK ip/ik,ip/ik,ip rozhoduje, jestli použít I MUL nebo I POWSTR 14