Thanks Scott Newell and John B C Walker for your comments on
single-stepping. I haven't quite thought everything all through
yet, but my concept on this feature was that it would be handled
mainly by the host application, which keeps a copy of the target
program (probably in an 8k unsigned int array -- int is usually 16
bits on a PC). When it receives the single step command from the
user it first checks to see if the instruction would modify the
program counter directly, such as ADDWF PC,SAME.

If so, it handles the whole thing internally and doesn't
necessarily send any commands to the target monitor. It has an
image of all the registers, including flags, INDF, etc., and if
this image is changed through one of these internal operations
then the new version is uploaded to the target before resuming.

If the single step instruction is a "safe" one then it could be
executed in the target. The next instruction after that could be a
jump to monitor, which contains code to save and restore
registers.

A subroutine call could be dealt with by allowing it to execute
after placing a breakpoint at the first location in the
subroutine. The host keeps track of the subroutine level and the
return addresses so that when a return, retlw or retfie is
executed a breakpoint can be placed at the return destination.

If possible, the monitor routine should have no calls of its own
so that it doesn't modify the stack. On entry to monitor it first
saves necessary registers and then waits for a host command.

 Looking at this example:

   movlw   INITIAL_COUNT
   movwf   count
loop:
   movfp   parm,W
   movwf   temp
   ...
   decfsz  count
   goto    loop

   movfp   temp,W

Suppose you want to run the program at full speed from startup,
break just before the loop and then step through it. To do this
you put a breakpoint where "movwf count" was, so now the program
looks like this:

   movlw   INITIAL_COUNT
   goto    Monitor_1
loop:
   ...

The loader PIC bumps MCLR- forcing the target to reset and run.
The program will break to monitor if the pgm logic path leads to
this point, with INITIAL_COUNT in 'WREG' in the registers window.

Then you single step each instruction in turn, replacing the one
after it with a goto Monitor_1. The decfsz count takes special
handling: when this opcode is executed, the following _two_
instructions are replaced:

   decfsz   count
   goto     monitor_1
   goto     monitor_2

This way, "count" is updated correctly, and the monitor knows what
the next execution address is (it receives both addresses through
host commands).

I don't like the idea of using interrupts for single stepping
because (a) the latency and (b) this ties up a resource I'd rather
leave free for the user. However I presume interrupts have to be
disabled globally while in single step mode.

> Now, single-stepping inside an interrupt without blowing the stack
> might get tricky!

Well, you could single step an interrupt routine just like a
regular subroutine by replacing its first instruction with a
breakpoint, step through it, and when you get to the retfie, you
just... ah... er... well, I never said it was a full featured
emulator!

(You won't be able to single step out of any subroutine if the
breakpoint was inside, because the system has no record of the
return address, and the stack itself is not addressable.)

Well, this is getting interesting; I'm learning new things
about the PIC-Eval all the time, and it isn't even built
yet.

Regards, D.M.