2015-10-08 1:30 GMT+02:00 Eliot Miranda <eliot.mira...@gmail.com>: > Hi Nicolai, > > On Wed, Oct 7, 2015 at 2:13 PM, Nicolai Hess <nicolaih...@web.de> wrote: > >> >> >> 2015-10-07 16:49 GMT+02:00 Marcus Denker <marcus.den...@inria.fr>: >> >>> >>> > On 07 Oct 2015, at 15:49, Marco Naddeo <nad...@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 >