Ricostruzione sorgenti in object pascal

[Stilgar]

Ciao.
Su suggerimento di normore, pubblico qui, un progettino che porto avanti a tempo perso.
E' ancora in fase di sviluppo.

Scopo:
Partendo da uno o più file .class (struttura del file class fino alla versione 1. produrre un file ".pas" compilabile.
Al momento sono arrivato a creare la struttura delle classi. I metodi nativi purtroppo non sono traducibili con questo tool.
Per i metodi che hanno del bytecode dentro sono arrivato a decompilare una sorta si assembly.
Ora resterebbe da capire come ricostruire la logica interna al metodo per poter ottenere un codice effettivo che, una volta compilato, abbia lo stesso comportamento di quello che la macchina virtuale ha eseguendo il .class

Allego anche qualche output prodotto a caso.

La documentazione da cui sono partito è qui : https://docs.oracle.com/javase/specs/jvms/se11/html/jvms-4.html

Stilgar

[nomorelogic]

Ora resterebbe da capire come ricostruire la logica interna al metodo per poter ottenere un codice effettivo che, una volta compilato, abbia lo stesso comportamento di quello che la macchina virtuale ha eseguendo il .class

potresti fare un esempio pratico?
anche una classe banale scritta a mano in java, giusto per capire

[Stilgar]

La parte di cifratura.
Oppure la gestione dei protocolli di rete.

Le swing.
😁

[nomorelogic]

swing è il sistema di java per l'interfaccia grafica o sbaglio?
quindi vorresti fare in modo che compilando in pascal uscisse fuori la stessa interfaccia

[Stilgar]

Anche.
Aggiungi che sono skinnabile 😜

[nomorelogic]

una cosa da niente insomma 

[xinyiman]

Anche.
Aggiungi che sono skinnabile 😜

E sticxxxi 

[Stilgar]

swing è il sistema di java per l'interfaccia grafica o sbaglio?
quindi vorresti fare in modo che compilando in pascal uscisse fuori la stessa interfaccia

Diciamo che non è lo scopo principale del progetto.

Tanto poi ci sono cose da ottimizzare a manella.

Anni fa tradussi lo StringTokenizer di java in Delphi.
Mi feci una classe wrapper per le stringe.
Era leeeeeeento come la morte.
Ho eliminato la creazione degli oggetti a favore delle stringhe native del linguaggio.
Riusciva a fare la separazione dei token in pochi millisecondi di file di qualche mega.

In altre parole. Se le cose dentro l'interprete funzionano decentemente, portate in nativo "paro paro" potrebbero essere una chiavica a livello prestazionale.

Un porting manuale di alcune parti del jdk sono state già fatte.
Pensate a Zeos.
Pensate ad alcuni helper che FPC ci mette a disposizione.

Stilgar

[nomorelogic]

praticamente vorresti fare una cosa speculare a questa
https://wiki.freepascal.org/pas2jni

non ho ancora visto i sorgenti, forse servirebbe un parser java

[Stilgar]

JNI è la parte per dialogare con la jvm direttamente.
Nel senso: Crei una wrapper java con i metodi marcati nativi. Crei la tua dll (per dirla alla Windows). I metodi diventano entry point della libreria.
Devono aver una determinata firma per poter essere agganciati correttamente. Tra i parametri ci sono i puntatori al contesto della jvm.

Ho scritto parecchio col JNI in c++. Ma si parla del lontano ... 19 anta Bei tempi quelli.
Stilgar

[nomorelogic]

ok, infatti avevo in mente un parser java
nel senso che poi da quello si potrebbe generare il sorgente pascal

[Stilgar]

Avevo iniziato a modificare il parser java (quello del compilatore) per generare codice pascal.
Funzionicchiava.

Il problema è che a volte ci sono dipendenza di cui non hai i sorgenti. Passavo più tempo a cercare i sorgenti e renderli visibili al "compilatore" che migliorare la generazione.
Mi sono rotto e ho intrapreso la strada "ad alzo zero".
In questo modo posso tradurre e fare reverese anche delle cosine di cui si sono persi i sorgenti
Stilgar

[nomorelogic]

forse può essere utile

ho trovato queste perle, quando si dice open source....

elenco delle unit (documentazione scarseggia ma intanto si sa quali sono) per scanning, parsing e rappresentazione tree di sorgenti pascal
https://wiki.freepascal.org/fcl-passrc

documentazione albero
https://wiki.freepascal.org/The_parse_tree#The_parse_tree

e, per finire: FPC internal
https://wiki.freepascal.org/Category:FPC_internals

premessa...
i sorgenti pascal, prima (1) vengono passati con scanner e parser per ottenere un albero
poi (2) l'albero si passa al compilatore backend ed avviene la generazione del linguaggio macchina per OS/processore

ora...
visto che c'è qualche problema con il reperimento di tutti i sorgenti java di un certo progetto
si potrebbe tentare lo scanning ed il parsing del JNI per ottenere lo stesso albero di cui sopra (1)
fatta una cosa del genere ( assurdo solo a pensarlo è vero ), i vari compilatori backend sono già pronti all'uso per (2) compilare per qualsiasi piattaforma già supportata

ok, ok
chiaramente detta così è facile, lo ammetto

Edit: >>
nel JNI infatti ci sono delle implementazioni che non esistono in FPC
bisognerebbe tradurre queste diverse visioni del linguaggio (esempio GC), non è cosa da poco
però si potrebbe iniziare piano piano con i programmi senza GUI
<<


però ci sono dei vantaggi innegabili

Edit2: >>
del resto c'è il pas2jni...
<<

[Stilgar]

Ok nomore.
Ma il jni parte da java e arriva al codice nativo.
Fare il giro come l'ho capito non centra nulla con il progettino in questione E' un altro thread :p

Stilgar

[nomorelogic]

si, altra cosa è vero