> From: Clyde Smith-Stubbs <clyde@HTSOFT.COM>
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Re: SoNoboby knows
> Date: Friday, 30 May 1997 18:43
>
> 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

How very true! :)

> 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.
>

I suspect that its because its a 16bit(co-operative) app running in a
32bit(pre-emptive) os (lets not fight over whether '95 is 16 or 32 - for
the purposes of this argument it doesn't matter a stuff)  The foreground
app gets the WM_MOUSE messages, which are running at something like
real-time priority, rather than the normal priority a normal app gets.

> 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.

This is a f***ing awful way to code for any windows program.  You can spot
the bad windows apps quite easily, BTW.  Set up the System Monitor and
watch for 100% processor usage.  Dead giveaway.

>
> 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.
>

Or use multithreading.

MikeS
<mikesmith_oz@relaymail.net>