[Pharo-project] Compiler bug!!!

Eliot Miranda eliot.miranda at gmail.com
Tue Mar 20 14:00:57 EDT 2012


Igor,

    great catch.  I prefer the attached.  Strictly, the index needs to be
fixed correctly before the node's size is determined, since it could change
(not in this bytecode set, but in some future one it could).


On Tue, Mar 20, 2012 at 8:38 AM, Igor Stasenko <siguctua at gmail.com> wrote:

> Here the simple method:
>
> at: index
>        <primitive: 60 error: x >
>        ^ x
>
> And its bytecode:
>
> <primitive: 60 error: x>
> 13 <81 41> storeIntoTemp: 1
> 15 <11> pushTemp: 1
> 16 <7C> returnTop
>
>
> Now, if i add this:
>
> at: index
>        <primitive: 60 error: x >
>        [:foo | 5].
>        ^ x
>
> I get following bytecode:
>
> <primitive: 60 error: x>
> 17 <81 42> storeIntoTemp: 2
> 19 <8F 01 00 02> closureNumCopied: 0 numArgs: 1 bytes 23 to 24
> 23      <20> pushConstant: 5
> 24      <7D> blockReturn
> 25 <87> pop
> 26 <12> pushTemp: 2
> 27 <7C> returnTop
>
> so, if we ignore the block closure bytecodes, we have:
>
> <primitive: 60 error: x>
> 17 <81 42> storeIntoTemp: 2
> 26 <12> pushTemp: 2
> 27 <7C> returnTop
>
>
> The problem is that for method context there are only 2 temps
> (argument + error code) .. but not 3 (index is zero-based).
>
> The fix should be simple.. in code which calculates the temp index for
> 'error code' temp.
>
> --
> Best regards,
> Igor Stasenko.
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120320/45c35f72/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MethodNode-generateusing.st
Type: application/octet-stream
Size: 2490 bytes
Desc: not available
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120320/45c35f72/attachment.st>


More information about the Pharo-dev mailing list