On Jul 16, 2013, at 8:55 PM, Udo Schneider <udo.schneider@homeaddress.de> wrote:
On 16.07.13 17:15, Marcus Denker wrote:
No. A decompiler has to be very specific for the code generated by the compiler. I thought so.
For Pharo3, we even opted to not support decompilation at all⦠(IR -> AST). We will instead save a higher-level representation that has much more information (e.g. names of variables). For deployment, people can strip the names, giving them the same "obfuscation" the decompiler provides now. Sounds reasonable - so if I generate IR (-> BC) from non-Smalltalk sources ... is there any recommended way to make the non-Smalltalk-source visible in browsers? Up to now I would simply generate IR/BC directly which would mean that a class would have a method but w/o the source.
Or do I miss a crucial piece here?
What you need to do for that is to implement a class that has the same public API as OpalCompiler and Compiler⦠Then you can set this is the compiler of your class (override #compiler on the class side). This compiler then takes care to create the CompiledMethod with your bytecode *and* your source. The tools *should* be able to display just anything, but that needs to be double-checked as we changed the tools a lot and there is no example of methods with non-smalltalk source right now. Implementing Debugger support is possible, too. For that you need to have a mapping between pc and source for your language. What we need is a tutorial how to all that based on a simple toy language ;-) Marcus