Spellingsjekker:
Sop/Club0 & Peter Van Geenhoven
De bedoeling is een compiler te schrijven van pico naar java. Dit fijnzinnig project werd bedacht door een tros assistenten op de hoogste verdieping van gebouw F. Door diezelfden werd dan ook de naam van dit project bedacht. Het eigenlijke nut van dergelijke compiler kan ik vaag snappen, maar de uiteindelijke uitwerking van hun plannen ontgaat me toch wel een beetje. Dus mijn eigen enige vooropgestelde doel is een goede pico naar java compiler af te leveren. Nano zal geen eval-functie bevatten omdat pico dat op het moment zelf ook nog bevat.
Pico is een versie die ik gecopieerd heb en geport naar gcc. Hier vormt zich natuurlijk wel een klein probleem omdat pico constant verandert. Daarom heb ik besloten een bepaalde versie van pico te nemen en daarmee te werken en geen nieuwe versies meer te aanvaarden. Ik kan niet heel de tijd blijven converteren van mac naar gcc om testen ten uitvoer te kunnen brengen. Als ik veronderstel dat er een fout in pico voorkomt (of iets zeer onverwacht gebeurt) dan zal ik daarmee de juiste persoon lastig vallen.
De hardware wordt verwacht een
PC te zijn
die over voldoende geheugen beschikt (20 MB will do the trick) en die
er in
slaagt java en windows'95 comfortabel te draaien. (Wat geen sinecure
is).
Points
of interest
How
to represent types at runtime?
Een voor de hand liggend antwoord in
objectgerichte
talen is: 'Als een object' (ge moet het maar kunnen bedenken). Ik zal
dit zeker
zo doen omdat java reeds ingebouwde classes als 'Integers, Booleans,
Floats,
Longints' en andere die allen afstammen van het basisobject 'Object'.
Hier
ontbreken wel array's, maar daar straks meer over.
How
to represent environments (at runtime)
Ik denk er aan een environment te
representeren als
een 'Environment Object' (die geïmplementeerd is in de runtime
library).
Eventuele optimisaties zoals het vergeten van de namen van variabelen
en met
nummers werken kunnen eventueel toegevoegd worden, maar hiervoor moet
dan ook
wel de environment-representatie worden aangepast. Ik zal zeker en vast
beginnen met het gewone opzoeken van namen in een lijst.
Arrays
van objecten:
vormen geen enkel probleem omdat in java
voor elk
object dat gedefiniëerd wordt een parallel object aangemaakt wordt maar
dan met
een array-voorkomen.
Functieobjecten:
Omdat in pico de functies first-class
zijn, moet ik
ook toestaan dat functies worden behandelt als ware het waarden. Een
functieobject moet zeker zijn environment kennen waarin hij
gedefinieerd is. De
implementatie van de functionbody zal worden verwezelijkt door gewoon
een
method te implementeren die de juiste parameters verwacht. De
toekenning van
een naam aan dergelijke lambda kan verwezelijkt worden door een
functie-object
toe te kennen aan de juiste naam in de juiste environment.
De formele functie parameters zullen als functieobject at compiletime gegenereerd en meegegeven worden. (zie bovenstaande functieobjecten).
De apply: vormt geen enkel probleem. Zie onderstaande tabel. Merk op dat deze tabel enkel geldig is op het ogenblik dat de receiver de parameters niet in een environment verwacht, maar wel op de stack. (kleine optimizatie).
|
Receiver's aantal parameters |
Caller's aantal parameters |
Implementation |
|
variabel |
variabel |
De variabele parameters steken reeds in een tabel, dus deze moet enkel meegegeven worden. |
|
|
constant |
De juiste parameters worden uit de tabel gelezen en meegegeven. |
|
constant |
variabel |
De compiler genereerd zelf zeer bewust een tabel en geeft die mee aan de receiver. |
|
|
constant |
De compiler berekend de parameters en geeft ze mee. |
Elke zichzelf respecterende interpreter en/of compiler heeft een lexicale analyzer en een parser. Beide zal ik zonder dralen uit Theo's code sleuren. Een alternatief was zelf nog eens het wiel uit te vinden en ze te schrijven in lex/yacc. Maar dit is eerder nutteloos.
Ik wil deze compiler voorzien van een parse-tree[1]. In plaats van zoals vroegere compilers de code die gelezen & geassembleerd is weg te gooien wil ik op elk ogenblik in staat zijn aanpassingen te maken aan reeds genomen beslissingen. Ik veronderstel dat ik hiervoor de abstracte grammatica van pico gewoon kan overnemen.
De variable-usage checker. Deze bepaalt waar en hoe een variabele gebruikt wordt. Dit is nuttig om nadien eenvoudige optimizaties te kunnen verwezelijken.
De symboltable om symbolen in te stockeren en eventueel (heel erg waarschijnlijk zelfs) in op te zoeken neem ik ook gewoon over uit pico (in de vorm van environments).
De codegenerator die java-code genereert.
De runtime-library is ook een
essentiëel
onderdeel van de compiler, hoewel deze wel geëxporteerd wordt.
Tijdschema
Verwijderen van de functionele parameters zoals 'a(b(),c()):...' en vervangen door een tussenlaag. Omdat hierbij nieuwe identifiers ingevoerd moeten worden, zal ik ook voor de standaard-identifiers een underscore moeten plakken. 27 december
Code genereren en ontwerpen van de runtime library. Belangrijk hierbij is dat zelfs de eenvoudigste functies zoals begin(..,..,.) moeten worden uitgevoerd in de runtimelibrary. (Dit omdat de 'begin' geherdefinieerd kan worden). Hetzelfde met al de andere 'keywords'. 27 januari
Toevoegen van usage data aan de variabelen zodat ik variabelen die alleen maar een toekenning krijgen maar nooit uitgelezen worden kan verwijderen. Variabelen waaruit na 1 toekenning, nooit meer gelezen wordt zijn ook interresant om weten. 27 februari
Zorgen dat de keyword-like natives (begin, if,...) inline worden gegenereerd op het ogenblik dat ze als variabele nooit een toekenning krijgen. 27 maart
The JAVA language specification
http://java.sun.com/...
The java class API
http://java.sun.com/...
The C programming language
Second edition
Brian W.Kernighan/Dennis M.Ritchie
Compilers, principles, tools
&
techniques
Alfred V.Aho, Ravi Sethi, Jeffrey D.Ullman
Structure and interpretation of
computer
programs
Harold Abelson and Gerald Jay Sussman
(voor het deel over het efficiënt opzoeken van variabelen)
[1] Dit in tegenstelling tot de compiler die ik vorig jaar schreef (een c-compiler voor een stack-machine)