On Jul 16, 2013, at 8:55 PM, Udo Schneider <udo.schnei...@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