Tartu Ülikool Matemaatika-informaatikateaduskond Arvutiteaduse instituut Ain Isotamm TRANSLAATORITE TEGEMISE SÜSTEEM Tartu 2012 Toimetaja: Ahti Peder Käesoleva õpiku väljaandmist on toetanud Euroopa Sotsiaalfondi projekt „Informaatika ja infotehnoloogia magistriõppekavade arendamine Tartu Ülikooli arvutiteaduse instituudis koostöös Eesti infotehnoloogiaettevõtetega“. Küljendus: Ain Isotamm Keeletoimetus ja trükk: Tartu Ülikooli Kirjastus Autoriõigus: Ain Isotamm, 2012 ISBN 978-9949-19-970-9 Tartu Ülikooli Kirjastus www.tyk.ee SAATEKS See raamat on mõeldud eeskätt TÜ matemaatika-informaatikateaduskonna üliõpilastele õppe- materjaliks ainete „Automaadid, keeled ja translaatorid“ ja „Transleerimismeetodid“ omanda- mise hõlbustamiseks, ent mitte ainult − võib juhtuda, et sellest on abi ka rakendajale, kes peab realiseerima mingil masinal mingi (programmeerimis)keele, s.o. kirjutama programmide (pro tekstide) interpretaatori või kompilaatori1. Selle raamatu esimene2 kaasautor pidanuks olema Mati Tombak, kes raamatu kavandamisel arvas, et ta katab teoreetilised teemad, ent kirjutamist alustades selgus, et selleks eeldatud aeg oli liiga optimistlik. Millest on siiralt kahju: minu teooria-alane tekst tugineb nende kaante vahel Matilt õpitule (esmatutvuseks oli ta loengukursus TRÜs 1974. a. sügisel, mis oli orien- teeritud kõigile huvilistele). Ja kui matemaatikateaduskonnas oli paarkümmend aastat hiljem (kevadel 1998) vaja leida lektor uue kursuse „Kompilaatorid“ (teooria rakenduslik osa pluss realisatsioon) jaoks ja kui Tombak kutsus mind seda tegema3, siis pidin nõustuma, kuivõrd polnuks eetiline keelduda. Samas polnud meil “elusat” mikroarvutitel töötavat TTSi (M. Tombaku eestvedamisel olid tehtud süsteemid Minsk-32, Iskra, Apple’i, CM-4, EC-1020 ja PC XT jaoks) ja et valdkonda terviklikult tunnetada ning mitte piirduda õppetöös pelgalt tahvliga, suvel enne septembrit realiseerida TTS, kusjuures − taas tunnetuse huvides − ei tundnud ma huvi eelmiste realisatsioonide andmestruktuuride ja neil töötavate programmide vastu (mis olnuks ka võimatu, kuivõrd “vanad tegijad”, eeskätt M. Tombak, Jaanus Pöial ja Viljo Soo puhkasid). Niisiis, teoreetiliselt oli kõik paigas ning realisatsiooniks võtsin endale vabad käed. Käes- olevas raamatus püüan tutvustada teoreetilisi põhitõdesid ja üht võimalikku realisatsiooni ühe võimaliku variandi − eelnevusmeetodit kasutava alt-üles-analüüsi − näitel. Süntaksorienteeritud transleerimise meetodeid on palju4; ma ei tea, et neid oleks suudetud vastuvaidlematult järjestada kehtestamaks etaloni. Seetõttu (ja sellegipärast, et meie õppe- vahendi eesmärk pole nende variantide tutvustamine, vaid näitamine, kuidas selline lähene- mine toimib) kirjeldame allpool kontekstivabadele eelnevusgrammatikatele baseeruvate (pro- grammeerimis)keelte sõnade (resp. programmide) analüüsi puude automaatset genereerimist ning variante (kui keel on programmeerimiskeel) nonde puude interpreteerimise kaudu kas programmi tulemuste väljastamist või neid resultaate arvutada võimaldava koodifaili (.exe- fail) genereerimist. Seejuures, tänapäeval ei üritata reeglina genereerida resultaatfailina ma- sinkoodi, vaid teksti mõnes muus, juba efektiivselt realiseeritud programmeerimiskeeles (nt. 1 Nii pidi nt. Ahti Peder (selle raamatu toimetaja) oma magistritöö koostamisel kirjutama translaatori oma- konstrueeritud keelele Formula. Ja selleks kasutas ta meie süsteemi, sj. oli oma roll ka juhendajal Mati Tomba- kul. Ning Formula polegi programmeerimiskeel tavamõttes (vt. lisa 12). 2 Teise kaasautorina tegutses üsna kaua Nikita Šipilov, kes käsitles oma bakalaureusetöös [Šipilov] regulaarseid grammatikaid ning regulaaravaldisi tuvastavate automaatide genereerimist ja neist asjust pidi ta meie ühises raamatus ka kirjutama mõned peatükid pluss lisad; paraku muutusid aga temagi plaanid. 3 Töötasin ikka veel majandusteaduskonnas ja olin õpetanud majandusküberneetika tudengitele mingis ulatuses (kriidi ja tahvli abil) seda ainet. Mati meeskonnas olin varem kirjutanud analüüsi hõreda puu moodustaja TTSi Minsk-32 versioonile ning osalesin tagasihoidlikul määral ka projektis Modula-2 → Forth. 4 Vt. nt. Jaak Henno ([Henno], lk. 101 jj.) raamatut. 3 Forth1 või assembler − nagu ka nende kaante vahel näidatakse Inteli assembleri jaoks), või mõni baitkood − meie TTSi jaoks tegid seda oma bakalaureusetöödes 2008. aasta kevadel Henri Lakk (Java baitkood) ning 2009. a. Einar Pius (MONO ja .NET). Joonis s1. Ajurünnak koos Mati Tombakuga, 1974. aasta. Mõteldes avaloengule matemaatikatudengite ees2, püüdsin muidugi ette valmistuda, ja pea- küsimuseks enda (ning oletatavasti auditooriumi) jaoks oli: miks on selline aine üldse õppe- kavas. Kuivõrd translaatorite kirjutamine oli juba ammu „tehasemeeskondade“ pärusmaa ning tõenäosus, et mõni minu kuulaja peaks tulevikus tõepoolest sellises meeskonnas grupijuhina tööle hakkama, ei tundunud ei siis ega tundu ka nüüd kuigi suurena. Ent mõtlesin välja mõned põhjendused. • Millegipärast on see teema vist kõikide arvestatava taseme IT-haridust andvate kõrg- koolide õppekavades (kui uskuda Internet’ti). • Mulle tundub, et teadmata, kuidas mingit programmeerimiskeelt realiseeritakse, pole võimalik toda keelt kui programmeerimisvahendit lõpuni mõista3. Ja paradoksaalsel moel on kerge tekkida arvamusel, et masin (pro translaator) on „tark“ ja suudab ise programmeerimisvigadega (nii süntaktiliste kui ka semantilistega) hakkama saada4. 1 Mati Tombaku meeskond realiseeris nii translaatori Modula-2 → Forth. 2 Olemata haritud matemaatik; olen lõpetanud TRÜ rahanduse ja krediidi erialal 1965. a. ning TPI aspirantuuri statistika üldteooria alal, milles kaitsesin ka kandidaadikraadi 1972. a. Vilniuses. Pean nentima, et ma pisut kartsin oma kuulajaskonda (hoolimata tõigast, et olen 1971. aastast olnud professionaalne programmeerija). 3 Hea sõber Tõnis Kelder põhjendas, miks ta võttis vastu Mark Nemenmani pakkumise teha C-kompilaator Minski tehase mikromasinale, järgmiselt: „Tahtsin teada, kuidas C toimib, ja parim variant selleks oli kompilaatori kirjutamine.” (vt. ka [Isotamm 2009], lk. 37 jj.). 4 Tegelikult olid viimased „täisinformatsiooniga“ illusioonivabad programmeerijad need, kes kirjutasid masin- koodi ilma operatsioonisüsteemi toeta (nagu TPI meeskond Eesti Raadio arvutuskeskuses, kus masina Razdan-3 tehasepoolseks toeks olid ainult primitiivsed sisend-/väljund- ja tüübiteisendusfunktsioonid (vt. nt. [Isotamm 2007], lk. 47 jj.)); operatsioonisüsteem peidab programmeerija eest vähem infot kui translaator. Ent − nii op- süsteem kui ka translaator on programmeerija jaoks „mudakiht“ inimese ja „raua“ vahel. Mõlemad teevad elu lihtsamaks, ent hägustavad tunnetust − eriti, kui ei tea, kuidas nad on tehtud, ja millised on sealjuures mada- laima taseme programmid. 4 • Programmeerimiskeelte realiseerimise kursus haakub orgaaniliselt meie instituudi teiste baaskursustega, nagu „Programmeerimine“, „Algoritmid ja andmestruktuurid (A&A)“, „Programmeerimiskeeled“ ning „Transleerimismeetodid“. Tundub, et kõik need kursused on tervikliku tunnetuse saamiseks vältimatult vajalikud. • Edasi, praktiliselt kõik A&A andmestruktuurid ja algoritmid on transleerimiskursuses kasutusel: stringid, ahelad, vektorid, massiivid, puud, magasinid, struktuurid, tabelid, järjestamine, paisksalvestus, automaadid jne. Seega, meie kursuse võtmine peaks toe- tama A&A praktilist väljundit (loe: tõsiseltvõetavust). • Tegelikult tuleb pea igal professionaalil lahendada ülesandeid, kus algandmed on min- gil moel organiseeritud ning nende protsessimiseks tundub otstarbekana kirjutada „preprotsessor“ − triviaalne translaator, saamaks mugavaid andmestruktuure. • Mõnikord on spetsiifilise ülesande lahendamiseks kasulik programmeerida translaator (alates grammatika koostamisest, näiteks [Peder, Tombak, Isotamm] ja selle abil üles- anne lahendada [Peder, Tombak]). Ja kümmekond aastat hiljem, lugedes David Gallesi raamatu [Galles] 1. peatüki sissejuhatust (lk. 1), oli pigem meeldiv kui üllatav tõdeda, et ka D. G. küsib endalt, miks peaks noor bakaeelik raiskama aega kompilaatorite kirjutamise tehnikale teadmises, et ta sellega kunagi tegelema ei hakka. Ja et põhjendusi on selles raamatus kolm. • Professionaal kasutab kompilaatorit iga päev ja see vahend ei tohi olla tema jaoks must kast, kui ta tahab kirjutada efektiivset koodi. • Ehkki väga vähesed meist kirjutavad iga päev kompilaatoreid, kirjutavad paljud meist nende juppe, näiteks HTML või XML alamhulkade interpreteerimiseks või siis muude andmestruktuuride mugavaks teisendamiseks. • Ja kolmandaks, kompilaatori kirjutamine sunnib meid olema kodus kõigis süsteem- programmeerimise valdkondades (automaadid, keerukad andmestruktuurid jne. jne.). Minu TTS-süsteemi esimene versioon valmis MS-DOSi keskkonnas (kasutades graafilise lii- dese valmistamiseks Stan Milami vabavaralist menüüde tegemise süsteemi), teine versioon − Windowsi keskkonnas − valmis paar aastat hiljem, tollase tudengi Gunnar Kudrjavetsi tungiva soovituse ja asjaliku teeleaitamise toel. Minu TTSi silmatorkavaim vajakajäämine seisneb seigas, et lekseemiklasside (identifikaatorid ja konstandid reaalselt, stringid ja kommentaarid potentsiaalselt) elementide tuvastaja on skannerisse „sisse programmeeritud“, selmet kasutada regulaarseid grammatikaid ja nende defineeritud sõnade (regulaaravaldiste) tuvastamiseks genereeritavat automaati. Mul oli selle asja jaoks paar hägusat ideed ja minu õnneks hakkas see teema huvitama Nikita Šipilovit, kes sai oma bakalaureusetöös [Šipilov] rakendatava resultaadi. Nagu juba ülalpool mainitud, ka- vatsesime tema tulemusi