On Jul 16, 2013, at 8:55 PM, Udo Schneider <[email protected]> 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
