[Pharo-dev] Order of evaluation bug with in lined to:do: in both Opal and Squeak compilers.

Eliot Miranda eliot.miranda at gmail.com
Thu Apr 20 19:41:53 EDT 2017


Hi All,

    just stumbled across a bytecode compiler bug that's in both the Squeak
compiler and the Opal compiler.  I'm told by Clément that Opal mimics the
bug to avoid crashing legacy code.  So there may be places that depend on
this bug.  It would be good to eliminate the dependencies and the bug.

For illustration look at the to:do: loop in the ifNil: arm in
Context>>privRefresh:

Context>>privRefresh
"Reinitialize the receiver so that it is in the state it was at its
creation."
closureOrNil
ifNotNil:
[pc := closureOrNil startpc.
self stackp: closureOrNil numArgs + closureOrNil numCopiedValues.
1 to: closureOrNil numCopiedValues do:
[:i | self tempAt: closureOrNil numArgs + i put: (closureOrNil at: i)]]
ifNil:
[pc := method initialPC.
self stackp: method numTemps.
method numArgs+1 to: method numTemps do:
[:i | self tempAt: i put: nil]]


This should evaluate method numArgs + 1 then method numTemps.  If it were
written as a non-in-lined (method numArgs+1 to: method numTemps) do: [:i|
self tempAt: i put: nil] then the [self tempAt: i put: nil] block would be
created next.  But the bytecode for the inlined version is

self stackp: method numTemps.
63 <70> self
64 <84 40 03> pushRcvr: 3
67 <D6> send: numTemps
68 <E1> send: stackp:
69 <87> pop

iLimit := method numTemps
70 <84 40 03> pushRcvr: 3
73 <D6> send: numTemps
74 <69> popIntoTemp: 1

i := method numArgs + 1
75 <84 40 03> pushRcvr: 3
78 <D2> send: numArgs
79 <76> pushConstant: 1
80 <B0> send: +
81 <81 40> storeIntoTemp: 0 (squeak) <69> popIntoTemp: 1 (pharo)
83 <10> pushTemp: 0
84 <11> pushTemp: 1
85 <B4> send: <=
86 <AC 0B> jumpFalse: 99

There is a second bug in the Squeak bytecode; storeIntoTemp: is used to
load i whereas it should be popIntoTemp:.  It was this second bug that
alerted me to the order-of-evaluation bug.

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20170420/4e2ac28e/attachment-0002.html>


More information about the Pharo-dev mailing list