<div dir="ltr"><div>Free books here:</div><div><a href="http://stephane.ducasse.free.fr/FreeBooks.html">http://stephane.ducasse.free.fr/FreeBooks.html</a></div><div> </div><div>Early Squeak was pretty similar to the description in</div><div> </div><div><a href="http://sdmeta.gforge.inria.fr/FreeBooks/BlueBook/">http://sdmeta.gforge.inria.fr/FreeBooks/BlueBook/</a></div><div> </div><div> </div><div>Karl</div><div> </div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 20, 2014 at 12:01 PM, Casey Ransberger <span dir="ltr"><<a href="mailto:casey.obrien.r@gmail.com" target="_blank">casey.obrien.r@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I don't know anything about how the Squeak decompiler works.<br>
<br>
One approach to translating code in one language to another is to build a parser for the source language in order to obtain an abstract syntax tree (AST) and then use a pretty-printer for the target language on the AST. That's the short, short version of an explanation of how we translate the Squeak VM from Slang to C.<br>
<br>
In the case of a decompiler for a byte compiled system, the source language (using the above approach) would be the bytecodes themselves, and the target language could be any language with sufficient facilities to support the semantics of the source language (in the case of a decompiler, the target language would be the original language used to compile the e.g. bytecode.)<br>
<br>
I hesitated to respond, because I definitely don't know anything about Squeak's decompiler, and also because what I've described is in some ways a massive oversimplification (if the compiler is optimizing things, deoptimization may be necessary to approach the intent and style of the original programmer's code, and that's just one thing I can think of.)<br>
<br>
We have available to us a couple of tools which make it (relatively) easy to play around with this idea and get a feel for it (OMeta/Squeak and PetitParser.)<br>
<br>
I'd recommend checking out PetitParser if you're messing with stuff to do with compilation, as OMeta's development seems to mostly have shifted to Javascript. PetitParser is actively maintained.<br>
<br>
Decompilation hasn't been an area of interest for me, and I don't know much about it, so I may be sending you down the primrose path. In the immortal words of LeVar Burton, "don't take my word for it."<br>
<br>
I know that several research papers have been written about OMeta, and I'd bet some have been written about PetitParser as well. The focus of these systems is on parsing expression grammars (PEGs,) but language to language translation is a thing, and it seems to me that a decompiler can be viewed as a special case of this thing. Following the references cited in such papers could prove valuable to whatever your cause is.<br>
<br>
For historical perspective on OMeta and PetitParser, it might be helpful looking into the meta language called Meta-2.<br>
<br>
Arguably, this question would be as well addressed on squeak-dev, as both the compiler and the decompiler are image-residents, and not built into the VM (though both are tied to the VM's behavior wrt interpreting bytecode.)<br>
<br>
HTH, sorry if it doesn't.<br>
<span class="HOEnZb"><font color="#888888"><br>
Casey<br>
</font></span><br>
P.S.<br>
<br>
People who actually know how Squeak's decompiler works should still probably chime in here :D<br>
<div class="HOEnZb"><div class="h5"><br>
> On Oct 20, 2014, at 1:51 AM, Whiter Walt <<a href="mailto:whiter.walt@gmail.com">whiter.walt@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> I am interested in the Squeak Decompiler class. Is there any technical information in the net, which explains the functionality? Or maybe it follows some common "rules", I can find in some paper or book?<br>
><br>
> cheers<br>
> Walt<br>
</div></div></blockquote></div><br></div>