2015-10-08 1:30 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:

Hi Nicolai,

On Wed, Oct 7, 2015 at 2:13 PM, Nicolai Hess <nicolaihess@web.de> wrote:

2015-10-07 16:49 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>:

> On 07 Oct 2015, at 15:49, Marco Naddeo <naddeo@di.unito.it> 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