+1, the comments helps to understand,
but this kind of stateful behavior sucks in the first place


2013/4/18 stephane ducasse <stephane.ducasse@free.fr>
I should say that I LOVVVVVVVEEEEE the comments in the method.
Yes Yes Yes.

Stef

>
> Yes, just the AST with Semantic Analysis information (Scope and Semantic Variables), plus
> bytecodelevel IR that provides the bridge to the low-level pc (bytecode mapping) data�
>
> e.g. to get the highlight in the debugger, this is now just this in DebuggerMethodMapOpal:
>
>
> rangeForPC: aPC contextIsActiveContext: contextIsActive
> � � � "return the debug highlight for aPC"
> � � � | pc |
>
> � � � "When on the top of the stack the pc is pointing to right instruction, but deeper in the stack
> � � � the pc was already advanced one bytecode, so we need to go back this one bytecode, which
> � � � can consist of multiple bytes. But on IR, we record the *last* bytecode offset as the offset of the
> � � � IR instruction, which means we can just go back one"
>
> � � � pc := contextIsActive ifTrue: [aPC] ifFalse: [aPC - 1].
> � � � ^(methodNode ir instructionForPC: �pc) sourceNode debugHighlightRange
>
>
>
> more helper methods will simplify this even more, e.g. we should have a method
> on RBMethodNode like #nodeForPC:
>
>
> rangeForPC: aPC contextIsActiveContext: contextIsActive
> � � � "return the debug highlight for aPC"
> � � � | pc |
>
> � � � "When on the top of the stack the pc is pointing to right instruction, but deeper in the stack
> � � � the pc was already advanced one bytecode, so we need to go back this one bytecode, which
> � � � can consist of multiple bytes. But on IR, we record the *last* bytecode offset as the offset of the
> � � � IR instruction, which means we can just go back one"
>
> � � � pc := contextIsActive ifTrue: [aPC] ifFalse: [aPC - 1].
> � � � ^(methodNode nodeForPC: �pc) debugHighlightRange
>
>
> And this method one then can just implement on MethodContext itself.
> (Caching is handled by ASTCache).
>
> � � � Marcus
>
>
>