2015-10-08 1:30 GMT+02:00 Eliot Miranda <[email protected]>:
> Hi Nicolai,
>
> On Wed, Oct 7, 2015 at 2:13 PM, Nicolai Hess <[email protected]> wrote:
>
>>
>>
>> 2015-10-07 16:49 GMT+02:00 Marcus Denker <[email protected]>:
>>
>>>
>>> > On 07 Oct 2015, at 15:49, Marco Naddeo <[email protected]> wrote:
>>> >
>>> > Hi,
>>> >
>>> > I have some problems with the large block at bottom:
>>> >
>>> > -sending the message argumentNames gives me an empty array #()
>>> > -sending the message sourceNode gives me a strange result and not a
>>> RBBlockNode, as I would expect
>>> >
>>>
>>> This happens already with:
>>>
>>> [ :h :s :v | | min chroma hdash X red green blue | ] sourceNode
>>>
>>> I will check… it is a bug in the mapping pc -> AST.
>>>
>>
>> That's interesting, the way the pc is mapped to the AST (ir
>> instructionForPC: )
>> takes the "length" of the instruction bytecode into account and the
>> length of a pushclosure includes
>> all bytes needed for the pushing the local temps (pushConstant nil.
>> pushConstant nil ....)
>>
>> But the startPC of a block context starts at the first push, not after,
>> that means
>>
>> self method sourceNodeForPC: self startpc - 1
>> starts the search after the push closure bytecode but before any push
>> local temp byte code.
>>
>> Either we don't include the bytecodes for the "pushConstant:nil" in the
>> bytecode offset, or we start the search at
>>
>> self method sourceNodeForPC: self startpc - 1 + self numLocalTemps
>>
>
> No, no, no, no, no :-).
>
I think I will always get confused by BlockClosure code at the bytecode
level :)
>
> self method sourceNodeForPC: self startpc - 4
>
We already have this little heuristic
instructionForPC: aPC
0 to: -3 by: -1 do: [ :off |
(self firstInstructionMatching: [:ir | ir bytecodeOffset = (aPC -
off) ]) ifNotNil: [:it |^it]]
AFAUI this 0 to -3 offset is used because we have 1,2,3 or 4 byte-length
bytecodes.
>
> and make sure that the compiler maps a block creation bytecode to the
> source node for the entire block.
>
in the above code (instructionForPC) we try to find the instruction for the
pc (here the pc of the closure creation code), but I don't really
understand what
"bytecodeOffset" is, it looks like (bytecodeIndex+startPC), but for a
IRPushClosureCopy, it looks like the bytecodeIndex does include
the number of local temps resp. (numberOfLocalTemps times the
bytecodelength for pushConstant:nil).
>
> The way to think about "self method sourceNodeForPC: self startpc - 1 +
> self numLocalTemps" not masking sense is that a pc inside the block must
> map to a statement inside the block, not the block itself.
>
>
Hm, I don't know :)
> HTH
>
>
>>
>>
>>>
>>> Marcus
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
