Re: Timer module for interpreter
- From: cs99cjb@xxxxxxxxx
- Date: 16 Feb 2006 18:30:57 -0800
Rory McLean wrote:
I'm trying to put together a interpreter which will cooperatively
multi-task with the WIMP.
This is written in C with the intention of running on RISC OS 3.1
upwards, and preferably also on the Iyonix. It is planned to port
this to Windows and Linux in due course, with the intention that
all three interpreter environments behave the same.
What I'd like to do is have a fall-back timer so that if some
code runs wild this will set a flag to halt the main interpreter
loop which is running the code. Conceivably this might make use
of longjmp.
I've googled but not found anything that looks likely. If I
understand things correctly the main interpreter loop needs to
call a module which sets up a timer, and that timer when it goes
off needs to set a value which is tested in the loop.
Why does it have to be a module? Presumably because you are worried
about your application code being paged out (inadvertantly or
otherwise) when the timer goes off. However I implemented a system that
sounds similar to what you propose without using a module.
Several of my applications use SWI OS_CallAfter to set a routine to be
called after a certain time interval has elapsed since control last
returned from SWI Wimp_Poll. This interval is configurable and it
dictates the granularity of multi-tasking and the amount of CPU time my
task gets compared to other tasks. (10 centiseconds is normal and
causes it to run at the same priority as a program in a TaskWindow.)
The ticker timer routine is called in SVC mode with interrupts
disabled. It is tiny and out of necessity written in assembly language;
it simply sets a flag at the address passed in R12. Because my ticker
event routine is in application space I also set up an atexit()
function so that the C run-time system will make a last-ditch effort to
remove it (SWI OS_RemoveTickerEvent) even if my program terminates
unexpectedly. The only reason the atexit() function might not get
called would be a 'No stack for trap handler' type error, but even then
it is extremely likely the ticker timer will go off before the user
dismisses the error report.
The only reason for all of this is that it is much more efficient to
check a boolean value in every loop where the number of iterations is
unknown (or known to be high) than it would be to repeatedly call SWI
OS_ReadMonotonicTime and compare the returned value with that recorded
after the last Wimp_Poll. The poll-wimp-now flag must be type-qualified
as 'volatile' so that the C compiler does not optimise away repeated
accesses.
If you are interested, the relevant code is c.RoundRobin, c.LoadSaveMT
and s.timer in CBLibrary:
http://starfighter.acornarcade.com/mysite/programming.htm#cblibrary
As an example client, my application SFtoSpr:
http://starfighter.acornarcade.com/utils.htm#sftospr
All of my desktop applications that do significant processing in the
background are written as state machines (with some functions that know
how to return prematurely when their time is up). However I don't see
why the ticker flag scheme outlined above couldn't instead be used to
determine the appropriate time to call SWI Wimp_Poll (or equivalent)
directly from within a deeply nested function. Of course you would then
have to guard against potential problems caused by re-entrancy.
The main interpreter loop is also calling Wimp_Poll at reasonable
intervals to allow cooperatively multi-task to continue. If the
code runs OK then the timer will be disabled, so that it doesn't
go off, and maybe reset and reenabled again later.
If the main interpreter loop is already calling Wimp_Poll then
presumably you are talking about some code running wild in such a way
that prevents it returning to the main loop within a reasonable time
period. AFAIK The only way to force a premature return without using
interrupts is to insert checks at strategic points.
HTH,
--
Chris Bazley
.
- Follow-Ups:
- Re: Timer module for interpreter
- From: Rory McLean
- Re: Timer module for interpreter
- References:
- Timer module for interpreter
- From: Rory McLean
- Timer module for interpreter
- Prev by Date: Timer module for interpreter
- Next by Date: Re: Timer module for interpreter
- Previous by thread: Timer module for interpreter
- Next by thread: Re: Timer module for interpreter
- Index(es):
Relevant Pages
|