[java] meteen bytecode of eerst source.

[Alarmnummer]

Ik ben de laatste tijd bezig met een klein taaltje, en het draait verder allemaal heel aardig. Ik heb op dit moment ook een evaluator zodat ik kan zien dat het ook werkt. Maar deze evaluator is dus weer een evaluatie framework bovenop die van de vm. Ik wil dus nu rechstreeks naar bytecode wegschrijven zodat deze overhead niet meer nodig is. Het enigste waar ik mee zit is dus de compilatie naar bytecode. Ik vraag me af of het handiger is om eerst sourcecode aan te maken en die te laten compileren door de compiler en dat te gebruiken, of om rechtstreeks bytecode aan te maken. Het voordeel aan een compiler is dat ik veel betere ondersteuning krijg met mijn vertalingsfouten. Het nadeel is dat er een extra stap nodig is.

Een van de onderdelen waar ik zelf erg blij mee ben is lazy-code generatie. Bij geparametriseerde types wordt als het nodig is code aangemaakt en hierdoor is bv recursieve polymorfisme ook mogelijk. Het nadeel hieraan is dat je dus onder het draaien extra tijd nodig bent om code aan te maken. Deze implementatie lijkt trouwens veel op die van Gyro

Maar wat is de meest handige aanpak? Ik ben trouwens nu 2 bytecode pakketten aan het bekijken:
http://www.gnu.org/softwa...code/package-summary.html
http://jakarta.apache.org/bcel/index.html

[edit]
Ik denk dat een databinding framework voor bytecode heel fijn zou zijn

[ Voor 4% gewijzigd door Alarmnummer op 26-04-2003 19:28 ]

[ACM]

Een algemeen geldend voordeel is dat de compiler nog eventuele optimalisaties kan uitvoeren, als je het naar source doet en de default compiler pakt.
Als die bytecode generators dat ook al kunnen is dat al weer een voordeel dat wegvalt

Bovenstaande is een van de redenen waarom vaak initiele versies van nieuwe talen de boel bijvoorbeeld naar C-code compileren en het dan verder aan bijv gcc overlaten

[Alarmnummer]

Daar heb ik ook aan gedacht. Maar bytcode wordt eigelijk niet echt veel geoptimaliseerd, dat doet de jit wel

[Verwijderd]

Het eerste bytecode pakket wat je noemt kan ik je afraden, want het is te specifiek voor een bepaald soort taal, omdat het een onderdeel is van de kawa scheme implementatie.

Maar waarom begin je gewoon niet met source code genereren dat is een stukje makkelijker? En als je achteraf toch bedenkt dan heb je maar kleine laag nodig tussen het genereren van sourcecode en het gebruiken van een bytecode pakket.

[Alarmnummer]

Verwijderd schreef op 26 April 2003 @ 21:53:
Het eerste bytecode pakket wat je noemt kan ik je afraden, want het is te specifiek voor een bepaald soort taal, omdat het een onderdeel is van de kawa scheme implementatie.

Ik kon de link van het gnu-bytecode project niet zo snel vinden. En er is niets mis mee hoor, Nice (zie mijn sig) gebruikt het ook.

Maar waarom begin je gewoon niet met source code genereren dat is een stukje makkelijker?

uhh.. bytecode genereren lukt me echt nog wel hoor

[Soultaker]

Alarmnummer schreef op 26 April 2003 @ 22:42:
uhh.. bytecode genereren lukt me echt nog wel hoor

Ik denk dat bytecode genereren moeilijker en tijdrovender is dan het genereren van Java code (maar dat hangt er ook een beetje vanaf in hoeverre je taal overeenkomt met Java, natuurlijk). Ik twijfel er niet aan dat jij het prima kan, maar ik weet niet zo zeker of het je belangrijkste doel is: ik kan me voorstellen dat het ontwikkelen en evalueren van de taal belangrijker is dan het schrijven van een snelle compiler (die waarschijnlijk niet eens veel efficientere code genereert).

Misschien is het genereren van je code ook wel een doel (omdat je dat gewoon leuk vind bijvoorbeeld, maar ook omdat je misschien een volledig op zichzelf staande tool wilt maken) en dan kan ik me voorstellen dat je toch bytecode gaat genereren, maar anders kun je waarschijnlijk beter de meest makkelijke oplossing kiezen zodat je je kunt concentreren op je hoofddoel. Ik heb het niet uitgebreid onderzocht, maar Java code uitvoeren lijkt me dus makkelijker.

[mbravenboer]

Java source code lijkt mij inderdaad ook veruit het handigst. De grootste voordelen zijn:

• bytecode controle gebeurt in principe pas at runtime, waardoor fouten (in het formaat of de inhoud) in de gegenereerde code ook pas at runtime bekend worden. Het hangt van je bytecode generatie framework af in welke mate dit geldt.
• je profiteert van de typechecker (en andere semantische checks) in de Java compiler
• je kan de output van je eigen compiler goed inspecteren
• Java begint langzaam aan weg te kruigen van Java bytecode. Vroeger was de relatie vrijwel exact 1 op 1 (bytecode was simpelweg geverifieerde Java), maar Java krijgt steeds meer mogelijkheden die de Java compiler desugared. Deze mogelijkheden kan je benutten als je naar Java compileert. Hierdoor wordt de gegenereerde code ook beter te gebruiken als API vanuit andere Java code.
• de Java compiler heeft diverse debug flags die bepalen hoeveel informatie over de sourcecode er in de bytecode wordt opgenomen. Als je zelf bytecode genereert, moet je zelf deze flags implementeren (of niet ...)
• je kan API documentatie genereren voor de gegenereerde sources, wat erg nuttig is als de code ook als API gebruikt kan gaan worden.
• Java source code kan in principe ook met een andere compiler gecompileerd worden, maar dit is niet echt een goede reden: de meeste supporten dan ook wel bytecode.

Optimalizatie in de Java compiler is in theorie ook een voordeel, maar speelt niet echt. De Java compiler doet vrijwel niets aan optimalisaties zoals je zelf al aangeeft.

[hobbit_be]

nou wel erg interessant: gewoon een practisch vraagje: moet je dan java.exe meesturen met je app of kun je gewoon de compiler er gewoon bijsteken in Java code? Soort van dynamic code ?

[Alarmnummer]

Maar als ik sources ga genereren dan moet ik ze ook kunnen cachen (althans de gecompileerde versies). Anders zal het geheel behoorlijk traag worden. Ik heb even zitten kijken naar Tomcat omdat ze daar ook zoiets doen. JSP wordt getransformeerd naar Java en dat gecompileerd. Helaas heb ik daar niet echt veel aan gehad.

Wie weet zo`n oplossing?

ps:
ik denk idd dat codegenereren misschien toch handiger is dan bytecode. Vooral omdat je sowieso al beter inzicht krijgt in wat er nu precies gegenereerd wordt.

[edit]
Op dit moment heb ik dus een kleine evaluator geschreven zodat ik alles kan testen. En ik heb daar ook exceptionhandeling bij zodat ik kan zien waar en wat er is fout gegaan (dus de taal kan zelf exceptions opgooien en je krijgt zo dan op een soortgelijke manier te zien als bij java, dus met een stacktrace). Ik heb hierbij perfect controle wat er gemeld moet worden als er iets mis gaat. In hoeverre kan ik daar nog controle over krijgen bij gegenereerde sources? Ik zou eventueel misschein nog iets kunnen doen aan de debug info die wordt meegenomen in de code en eventueel een vertaalslag te leggen op het einde.

[ Voor 38% gewijzigd door Alarmnummer op 27-04-2003 12:10 ]

[mbravenboer]

Alarmnummer: Wie weet zo`n oplossing?

Misschien dat een compiling classloader een aardige oplossing is als je echt at runtime code wilt genereren. IBM developerWorks heeft dit eens besproken:

http://www.panix.com/~mito/articles/#classloader

exceptionhandeling

Als je een taal A naar een taal B gaat compileren, is het handig om te kijken hoe je de features van taal A kunt vertalen in features van taal B. Omdat taal B alle mogelijkheden biedt, is het erg eenvoudig om geavanceerde mogelijkheden in taal A te bieden: je hoeft het slechts te vertalen in taal B. Nice is hiervan denk ik een goed voorbeeld. Misschien dat je je hier ook vooral op de vertaling in Java moet richten: hoe kan je Java exceptions gebruiken voor de exception handling in jouw taal?

[mbravenboer]

hobbit_be: moet je dan java(c?).exe meesturen met je app of kun je gewoon de compiler er gewoon bijsteken in Java code?

Je kan in principe gewoon de compiler in een J2SDK gebruiken. Je kan de Java compiler aanroepen via Runtime.exec(), maar ook direct vanuit Java omdat de Java compiler immers geimplementeerd is in Java. Hij zit in tools.jar. Tegenwoordig mag je deze Java compiler ook distribueren met je applicatie, vroeger was dat niet toegestaan.

Jasper, de JSP compiler van Tomcat, roept de Java compiler aan via Ant.