hi!

this is MPLAB question #497 - i spared you all questions 0-496, but
this one is buggin' me.

please think back over all the debuggers and all the simulators you've
used and tell me how many did things the way MPLAB does with respect to
breakpoints.

MPLAB breaks *after* the instruction at an address has executed. this
lands you up, at times, miles away from the breakpoint (GOTO, CALL).

this is, i swear, not the case in any other debugger/simulator i've
ever used and i am finding it mighty hard to get used to and a bit of a
challenge, so i guess i'm looking for you to say you agree or that it's
OK, i'll figure it out one day.

i remember implementing breakpoints myself (never mind how long ago) and
it seems that it would actually be harder to do it MPLAB's way.

it seems more logical, not just that i am used to it - after all, if
you want the MPLAB behaviour from another debugger, all you gotta do is
"step" once after a break-before-execute-type break point, while with
MPLAB, there is no work-around except in some cases adding strategic
NOPs to one's code. and as i say, that doesn't handle all cases.

have i overlooked a switch or option that would make the breakpoint
take effect *before* the instruction at the address?

orperhaps i have overlooked an "unstep" hotkey in MPLAB?

i'd supply examples of the really frustrating cases, but i figure
either you know what i'm talking about or you don't have much use for
breakpoints. :-)

i guess i should not complain, the price of MPLAB is certainly right (!),
i just would like to read  a coherent defense of this design decision
and then i might shut up and get over it and get used to it and make do
as best i can.

thanks.

-- rob