Thus spake David Gould (dg@ILLUSTRA.COM):

> > >and noboby knows why you have to
> > >move the mouse during simulation of one's machine code, to get it to
> > >'run to' quicker,
>
> Just guessing here, but most modern (last 3 years) PCs go into reduced clock
> power save modes (Energy Star Green PC (tm)) if there is no "user" activity

Good guess, but it's not the reason. I don't know what the exact reason
is either, but it has something to do with certain programmers not knowing
how to handle Windows events properly. There are a number of things about
MPLAB that suggest its internal program structure is a little odd. For
example, if you have a source file window open and a program window open,
and you try to set a breakpoint in the source window, sometimes it will
instead set one at the corresponding line (i.e. window line, not program
location) in the program window. Sometimes you can even click on the scroll bar
arrows in the source window and see the program window scroll instead!

It seems to get confused sometimes about which window events belong in
which window.

Regarding the mouse and emulations speed, it seems that MPLAB has a timer
running that posts WM_TIMER events to its queue, at about a 5 Hz rate. I
suspect that it waits for these events, during which time it does nothing.

When the mouse is being moved, WM_MOUSExxx events and others get posted
to the queue, causing the wait for event call to return immediately. If you
monitor CPU usage of MPLAB (use the task manager window under NT) MPLAB
while simulating is using only 9% or so CPU time! But moving the mouse
rapidly can boost this to 60% or more. Since simulation is CPU intensive,
it must be spending the idle time waiting on the event queue.

One could be led to suspect that someone didn't have a queue :-) I surmise
that the programmer knew she had to be prepared to accept events (like
clicking the STOP button (why the stop and start buttons and keys are
different is another mystery) and decided to do this by starting a timer,
and periodically waiting on the event queue, relying on the timer to end
the wait after a short interval. This probably worked ok on a slow machine,
where the timer period was well matched to the time spend simulating between
GetMessage() calls, but on a faster machine most of the time is spent
waiting for the timer to expire.

The correct technique is, of course, to call PeekMessage() every so often
(like every several thousand instructions simulated) which is a non-blocking
test for queued events. If it returns an event, it can then be
dispatched and handled before (possibly) resuming simulation.


--
Clyde Smith-Stubbs    | HI-TECH Software,       | Voice: +61 7 3354 2411
clyde@htsoft.com      | P.O. Box 103, Alderley, | Fax:   +61 7 3354 2422
http://www.htsoft.com | QLD, 4051, AUSTRALIA.   |
---------------------------------------------------------------------------
Download a FREE beta version of our new ANSI C compiler for the PIC
microcontroller! Point your WWW browser at http://www.htsoft.com/