[squeak-dev] Tests.Compiler.DecompilerTests.testDecompilerInClassesMNtoMZ

Levente Uzonyi leves at elte.hu
Fri Apr 12 17:23:10 UTC 2013


On Fri, 12 Apr 2013, Frank Shearar wrote:

> This, and the other decompiler test failure, happens because of the
> recent chained assignment work:
>
> original snippet:
>
>    ActiveWorld := ActiveHand := ActiveEvent := nil.
>
> decompiled version of sameL
>
>    ActiveEvent := nil.
>    ActiveHand := nil.
>    ActiveWorld := nil.
>
> How to fix?

The only method with this assignment chain in my image is MorphicProject 
>> #saveState . The bytecodes for this line are:

73 <73> pushConstant: nil
74 <81 C5> storeIntoLit: ActiveEvent
76 <81 C6> storeIntoLit: ActiveHand
78 <82 C7> popIntoLit: ActiveWorld

And the decompiler can reproduce the original code.

If I recompile this method (which should have been done due to the 
Environments changes, but for some reason it hasn't happened yet), then 
there's a bug in the compiler. The bytecodes will be:

78 <25> pushConstant: ##ActiveWorld
79 <73> pushConstant: nil
80 <27> pushConstant: ##ActiveEvent
81 <80 41> pushTemp: 1
83 <CA> send: value:
84 <87> pop
85 <26> pushConstant: ##ActiveHand
86 <80 41> pushTemp: 1
88 <CA> send: value:
89 <87> pop
90 <CA> send: value:
91 <87> pop

Which are obviously wrong.

Creating a new method with just a simple assignment chain:

foo

 	GlobalA := GlobalB := $a

generetes:

25 <20> pushConstant: ##GlobalA
26 <22> pushConstant: $a
27 <21> pushConstant: ##GlobalB
28 <80 41> pushTemp: 1
30 <CA> send: value:
31 <87> pop
32 <CA> send: value:
33 <87> pop
34 <78> returnSelf

Which still has the pushTemp: 1. But this method has 0 temporaries, so 
it's a compiler bug. I wonder how the decompiler can decompile anything
meaningful from this, and how the VM doesn't crash.


Levente

>
> frank
>
>


More information about the Squeak-dev mailing list