High priority interrupts.
Gavin...@ultracontrols.aero
getting Julian Highfield's T414 emulator working within a command
console under Vista. It now supports both the Occam and C toolsets.
The last modification I added was the ability for a high priority
timer process to interrupt a low priority process, when the timer had
expired. This has now been tested and is fully working. This uses the
reserved memory space just above the link addresses.
I now have a couple of questions which need answering before I
complete the interrupt changes. These need someone who has in-depth
internal transputer workings (i.e. ex Inmos).
There are two questions I need answering, which are defined below.
Case 1. Assume a low priority process is running. What happens when a
high priority process is ready to runs after a channel (in or out
instruction) is completed and hence the high priority task is able to
be put back on the high priority queue by the scheduler. Does this
cause a high priority interrupt of the low process running, instead of
the task being added to the high priority queue?.
Case 2. Again assume a low priority process is running. What happens
if the low priority task causes a high priority task to be executed
(runp or startp instruction). Does this cause (done by the scheduler)
a high priority interrupt (i.e. by the new high priority task) of the
low process running, instead of the task being added to the high
priority queue?
The above is based on the fact that a high pri task will run until
completion or a descheduling point, and a low priority process will
only run if there are no high priority task on the queue / or running.
Also that it is assumed that the low priority task is executing a
large number of instructions which are NOT descheduling points.
All sensible thoughts appreciated.
Gavin
James Harris
> As some of you are aware I have spent the last year or so (on and off)
> getting Julian Highfield's T414 emulator working within a command
> console under Vista. It now supports both the Occam and C toolsets.
>
> The last modification I added was the ability for a high priority
> timer process to interrupt a low priority process, when the timer had
> expired. This has now been tested and is fully working. This uses the
> reserved memory space just above the link addresses.
>
> I now have a couple of questions which need answering before I
> complete the interrupt changes. These need someone who has in-depth
> internal transputer workings (i.e. ex Inmos).
>
> There are two questions I need answering, which are defined below.
>
> Case 1. Assume a low priority process is running. What happens when a
> high priority process is ready to runs after a channel (in or out
> instruction) is completed and hence the high priority task is able to
> be put back on the high priority queue by the scheduler. Does this
> cause a high priority interrupt of the low process running, instead of
> the task being added to the high priority queue?.
AIUI if one high priority process is ready to run it will run,
normally after completion of the current instruction. The registers of
any interrupted low priority process will be saved first. The
instruction set manual and compiler writer's guide (section 6.3)
reports there being the following interruptible instructions: move,
input, output, dist, taltwt, tin.
>
> Case 2. Again assume a low priority process is running. What happens
> if the low priority task causes a high priority task to be executed
> (runp or startp instruction). Does this cause (done by the scheduler)
> a high priority interrupt (i.e. by the new high priority task) of the
> low process running, instead of the task being added to the high
> priority queue?
The same book in 6.3.4 says "when a high priority process becomes
ready ... the low priority process is interrupted."
>
> The above is based on the fact that a high pri task will run until
> completion or a descheduling point, and a low priority process will
> only run if there are no high priority task on the queue / or running.
Do high priority tasks recognise descheduling points? I have an idea
they only apply to low priority processes. May not be right, though.
> Also that it is assumed that the low priority task is executing a
> large number of instructions which are NOT descheduling points.
Is this relevant? Won't the processor only honour descheduling points
after a timeslice has been flagged as being necessary?
James
Alec Cawley
rescheduling points. Particularly jumps, but also in and out etc. At
rescheduling points, the programmer should assume that the operand
register and operand stack may be corrupted. Rescheduling, whether
becasue of channel operations (hard and soft) or timeslicing will only
take place after these instructions.
In and out are two of such instructions, so the switch occurs upon
completion of the instruction - very simple. For hardware channels,
including the Event channel, the switch will not occur until the CPU
next executes a reschedulable instruction - usually a jump. In theory
you could lock out the switch by executing a long series of
non-branching instructions, but in practice this doesn't happen (unless
you do a shift of a brillion places, in which case effective execution
stops for minutes).
I think that there are actually two PC and SP registers, and therefore
one task is "active" on each (i.e. not in the queue) at any time.
Changing priority, up or down, is just a matter of choosing which pair
to use, no no memory accesses take place at all. The Operand registers,
of course, remain the same, so that there is a "leakage" from one thread
to the other - or, as it would usually be seen, corruption.
Alec
Mike B.
> high priority process is ready to runs after a channel (in or out
> instruction) is completed
interruption
> Case 2. Again assume a low priority process is running. What happens
> if the low priority task causes a high priority task to be executed
> (runp or startp instruction).
runp: interruption if (Areg & 1) == 0 else add to low priority queue
startp: add to appropriate priory queue (no priory change possible!)
> Also that it is assumed that the low priority task is executing a
> large number of instructions which are NOT descheduling points.
????? there should be no such assumption.
Descheduling on descheduling points is a independent mechanism of low
priory round robin based process execution.
You should also consider the circumstances that in Case 1 there may be
NO active low priority process. Don't reanimate random values as a
process after you return from the interruption.
Ideally - interruption must be aware of "interruptible instruction".
But you can ignore this fact and make all interruptible instructions
uninterruptible, because you are running in a "non-realtime"
environment.
-Mike
Mike B.
Descheduling on TIMESLICING POINTS (j,lend) is a independent mechanism
of low
priory round robin based process execution.
-Mike
Gavin...@ultracontrols.aero
> large number of instructions which are NOT descheduling points.
What I was meaning when I wrote the above was simply to set the
scenario for the above two cases (1 and 2), where the low priority
process was being FORCED to run for an extended period (e.g. a
succession of addition instructions). That is, the process was being
starved of any descheduling points.
Gavin
Gavin...@ultracontrols.aero
> NO active low priority process. Don't reanimate random values as a
> process after you return from the interruption.
If there is no active low priority process runing then an interrupt
would not occur ????
Mike B.
Yes, you are right, but where is the information stored, that the
values between #8000002C-44 are valid? A simple "global state flag"
like Analyzed for the "test processor analyzing" instruction or is
WdescIntSaveLoc = NotProcess.P? Is Bit0 in this location always 1 or
ignored?
There are some multipriority scheduler implementation which may
requires such a pedantict emulation.
And (for my opinion) - there are many "open" questions which have to
be identified on real hardware like:
What is the content of Breg after a STNL? Goes Creg directly to Areg
or "over" Breg?
What happens if Wptr & 3 != 0?
What meaning has the different bits in STATUSIntSaveLoc?
....
I don't want to scare you. But this questions and there exploration
has prevented me from writing an emulator (so far).
But - stay tuned!
-Mike
Gavin...@ultracontrols.aero
> values between #8000002C-44 are valid? A simple "global state flag"
> like Analyzed for the "test processor analyzing" instruction or is
> WdescIntSaveLoc = NotProcess.P? Is Bit0 in this location always 1 or
> ignored?
According to the compiler writer's guide p.95, if no low priority
process was executing when the high priority process started then
WdescIntSaveLoc will contain NotProcess.p and the other locations
(i.e. #8000002C-40) will contain undefined data. If a low priority
process was executing then all the locations will contain valid
dataexcept EregIntSaveLoc which is only valid if a block move was
interrupted.
As present the existing emulator uses a global flag to indicate if a
high pri task has interrupted low pri task. Not quite the same as the
real thing, but hey it is only an emulator!
Gavin
Gavin...@ultracontrols.aero
> of low priory round robin based process execution.
Agreed that the j and Lend instructions are for low priory
descheduling, however...
I believe that there is a hidden register (SNPFLAG) within the
Transputer (hinted at in the Inmos Transputer Patent) that is set when
the low priority time slice period has been reached.
Once this is set it forces the scheduler to cause the running low
priority process to deschedule when it reaches and completes its next
descheduling instruction in, out etc. (AND ... it includes the j and
Lend instructions too).
Gavin