Post by thread:MPLAB question

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

"robert a. moeser" wrote: > > 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 ... This is a function of the emulator hardware used in the PICMASTER and ICEPIC. The hardware "sees" the breakpoint address, then breaks. Due to the one-cycle lookahead of the PIC, this means the the instruction is already being executed when the emulator "sees" the address. Hence, the break is at the address AFTER the breakpoint. When MPSIM was integrated into MPLAB, it was decided that, in order to minimize confusion, it should work the same way. When MPLAB-ICE 2000 was released, it did breakpoints in a different way. (I can expound upon this if you are interested). So the break is at the address, and MPLAB-SIM was adjusted to mimic that. BTW, many hardware type breakpoints on fast, pipelined processors will exhibit this behavior, which we in the industry call "skidding." If a processor has such a deep pipeline, more than one instruction can get executed before the actual break occurs. Again, MPLAB-ICE 2000 can exhibit "skidding" if you use the complex breakpoints to get a break, but not if you are just setting breakpoints at addresses. PICMASTER, and every emulator that uses the same emulator silicon as PICMASTER, will always exhibit this one instruction "skid." -- ___________________________ | Darrel Johansen | | tempe, arizona | | spam_OUTdarreljTakeThisOuTprimenet.com | |_________________________|