[fpc-pascal] TPLY

Thierry Coq tcoq at free.fr
Fri Oct 29 11:19:13 CEST 2010


Brian,
thanks for the diff, I'll take it into account and publish an update.

On 28/10/2010 18:50, Brian Winfrey wrote:
...
> The changes I made in this diff were simply to get it to compile.
>
> Subsequently I renamed all files and folders to lowercase, converted
> spaces to underscores and added a prefix to eliminate duplicate file
> names where needed.
>
>    
...
>> Another approach would be to look at (and reverse engineer) the byte code.
>> If it's not obfuscated, it might even be easier to parse and port than the
>> native Java.
>>
>>      
> How would you suggest I proceed in that.
>    
>
Using the class file format (for example here: 
http://en.wikipedia.org/wiki/Class_%28file_format%29),
it would be easy to parse through the tables, identify the class name, 
its super class name, the interfaces it's implementing, and even the 
public and private methods. The java compiler has done all the work into 
translating the java code into nice tables. ;-)
I remember I did the exercise once. I've destroyed the code, but I could 
do it again. I remember one of the more difficult parts was 
understanding how java coded strings ;-) This was before anonymous 
classes and methods, so this could be another difficulty. I don't know 
how these are converted to byte code.
Once you have the structure, you can generate the pascal code. I would 
recommend against generating one class per unit as Java does: since 
pascal dependency rules are strict (no cycles), this would most 
certainly result in uncompilable code. What I do when I translate Java 
is to pre-declare all classes and interfaces at the top of the unit(s) 
and then generate the full class interface further down.
Translating the statements inside the bytecode I haven't tried, since my 
efforts were mostly for analyzing java code and measuring it.
I hope this helps,
Thierry




More information about the fpc-pascal mailing list