[comp.sys.transputer] Interrupts

csajp@its63b.ed.ac.uk (A Paxton) (05/21/88)

figueira@irisa.UUCP (Carlos Figueiras ) writes

> In "the transputer instruction set - a compiler writers' guide."
> document, it states (page 30) :
> 
> > To minimise the time taken for an interrupting priority 0 process
> > to start executing the following instructions are interruptable
> > ...[follows a list of only 6 instructions]
> 
> What does it actually mean ? 
> Does a high priority process waiting for a timer input resume execution
> immediately or should it wait for the current low priority process to
> execute one of those 6 instructions ???
> 
> In fact, a friend of mine interested on real-time applications with
> transputers did some experiences and it seems to behave as it should,
> that is immediate resuming of the high priority process when the timer
> reachs the programmed delay.

There are a few transputer instructions that take massively long times to
execute, notably some block I/O stuff. If your process is running at low
priority (level 1?) and a level 0 process interrupts, some info will be
stored in those bits of memory they don't like you touching, that enables
the instruction to be resumed. So the level 0 process can take over. This
is totally different from descheduling a level 0 process for another one on
a time slice. The level 0 process can interrupt after any instruction, but
only DURING those 6 listed.
   Note that because of the way the transputer is microcoded, some instructions
you wouldn't normally suspect can take forever (or too long, in real time) and
may not be on the list of 6 (I haven't got the guide here now to check). See
the notes in the compiler writer's guide for details, I am thinking of things
like shift instructions with a shift count in the millions, when the thing just
blindly keeps shifting. These just have to be programmed around.

            Alan Paxton. CS dept. University of Edinburgh

JANET  csajp@uk.ac.ed.itspna
UUCP   ...!uunet!mcvax!ukc!itspna!csajp
BITNET csajp%uk.ac.ed.itspna@UKACRL

[ These are my opinions only. I like them the best  .-) ]
                                                    Alan