+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