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[15] &= ~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)?
Update:
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
pseudo-SWI.
The exact timing seems to vary, but this is otherwise perfectly
reproducible.
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.
Jake
_______________________________________________
Rpcemu mailing list
[email protected]
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
