[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
|