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 :-).  The PC in question is the pc of the block creation
byte code.  The startpc of a block is the first bytecode following the
block creation byte code.  That *includes* any pushConstant: nil byte codes
establishing temps in the block.  Instead, it is expected that "self method
sourceNodeForPC: self startpc - 1" answers the same as "self method
sourceNodeForPC: self blockCreationPC", where self blockCreationPC is the
pc of the block's block creation bytecode.

In Squeak we have
BlockClosure>>blockCreationPC
"Answer the pc for the bytecode that created the receuver."
| method |
method := self method.
^method encoderClass
pcOfBlockCreationBytecodeForBlockStartingAt: startpc
in: method

This is because we support (as you will soon enough) different byte code
sets so it is wrong to assume the size of the block creation bytecode is
4.  But for now you could use

self method sourceNodeForPC: self startpc - 4

and make sure that the compiler maps a block creation bytecode to the
source node for the entire block.

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.

HTH


>
>
>>
>>         Marcus
>>
>>
>>
>>
>>
>>
>


-- 
_,,,^..^,,,_
best, Eliot

Reply via email to