has run. This ensures that the prev_eip and prev_esp that is used
for tracing and breakpoint checks is correct even in the cycle after
an interrupt or trap.
in performance, but I did not check the debugger carefully enough while
testing them. Part of the performance gain in main.cc revision 1.33 and
cpu.cc revision 1.9 was to allow bochs to stay in the cpu loop forever
in a single processor simulation. (In a multiprocessor simulation it must
quit the loop periodically to give the other procs a chance to simulate
too. Cooperative multiprocessing?) In the process, I restored calls
to BX_TICK in the cpu loop for 1-proc simulation only, and removed them
from the outer loop. (See main.cc, since it was done right.) However
I never made the equivalent change in the debugger code, so in the
debugger, there were ticks coming from the cpu loop and then an
equivalent number of ticks coming from the debugger code just outside
the cpu loop. The result was, of course, that simulation time went
at 2x the correct rate. This simulation time speedup was made even
worse because the continue loop in the debugger would increment ticks
by one quantum (5 at the time) no matter how many instructions had
actually been executed. So in trace mode in particular, the way it was
implemented before today, cpu loop would run only one instruction at
a time and the simulation time would get incremented 1+5=6 times! One
tick from the cpu loop, then 5 erroneous ticks from the continue loop.
Anyway, much of this nonsense should be fixed now. For uniprocessor
simulations, only the cpu loop does ticks (for best performance). For
multiprocessor simulations, the cpu loop exits after one quantum and
the code that calls the cpu loop gets to increment ticks instead.
> This patch fixes a number of debugger problems.
> - with trace-on, simulation time would pass 5x faster than usual, so
> interrupts and other timed events would happen at different times
> - with trace-on, breakpoints were ignored
> - with trace-on, control-C would not stop the processor and return to the
> debugger.
>
> This patch changes the execution quantum for the debugger to 1, which means
> that cpu_loop is asked to do one instruction at a time. This may cause
> bochs with the debugger to be slower than before.
>
> I haven't tested without the debugger yet, so I don't know if the timing
> of events matches or not.
