[Rpcemu] Improving CPU usage when idle
jake at waskett.org
Fri Apr 10 02:38:00 PDT 2009
On 09/04/09 17:36 +0100, Jake Waskett wrote:
> [re ARCEM_SWI_NANOSLEEP, Theo Markettos wrote]
>>> I did try changing it to usleep()
>>> some small amount and it was better, but still not good enough. Maybe
>>> it wants an equivalent of select() on the appropriate thread status
>>> (timer updates, mouse clicks)
> Now here's a very strange thing. I've just tried the following:
> In ArmDynarec.c:opSWI(), I've commented out *all* of the code in the
> "else if (templ == ARCEM_SWI_NANOSLEEP)", except for the last line of
> that block ("armregs &= ~VFLAG").
> Now this means that the SWI ought to be a no-op. However, what
> *actually* happens is that the BASIC "Sleep" program still causes RISC
> OS to become unresponsive to mouse clicks. (Interestingly, SWI 0x1c
> [OS_Mouse, which in turn causes getosmouse() to be called] is invoked
> far less frequently when "Sleep" is running.)
> Stranger still, I edited the "Sleep" program to comment out the
> NANOSLEEP SWI. Logically, this ought to have essentially the same effect
> as calling a no-op SWI. However, what *actually* happens is that
> system is perfectly responsive.
> This is peculiar, to say the least. I still suspect a timing problem,
> but I'm less than certain. I'd be interested to know if this
> behaviour is platform-dependent. Can anyone replicate these results
> on any other platform (I'm using Linux)?
Something else is strange, too. I have been able to eliminate my
event-queueing code as a cause of the following by using an otherwise
clean copy of rev 167 from SVN.
If "Sleep" is allowed to run (when the source code is modified such
that the SWI is a no-op), then after perhaps 3-4 minutes, the
frequency of calls to getosmouse() suddenly increases. A few seconds
after that, an error box appears, reporting that Sleep has encountered
an error. The error is SWI &56ac3 not known -- 56ac3 is the NANOSLEEP
The exact timing seems to vary, but this is otherwise perfectly
I have also seen the same problem when using unmodified code. The
only difference is that, when nanosleep() is actually called, the
error takes rather longer to occur. For that reason I haven't tried
to characterise it.
The problem does *not* occur (as far as I can tell) in the
interpreter. That is, it *only* occurs when the --enable-dynarec
option is given to the configure script.
...which may point towards a bug in the dynamic recompiler.
More information about the Rpcemu