Help - Another high priority interrupt mechanism problem to chew over.
Gavin Crate
server, I come across an interesting problem whilst debugging the high
priority interrupt mechanism.
The Problem
Assume a low priority task is running. It gets interrupted since a
high priority task needs to run (due to say a timer has become ready).
The high priority task runs and one of its instructions requires the
low priority (previously interrupted) to be rescheduled on the low
priority queue.
If it rescheduled the task on the low priority queue, then there would
effectively be two occurrences of the same thread – the one
interrupted and the one on the queue?
Can the above happen on the real T414 device? My thoughts are yes, it
the low priority task is handling an Occam ALT statement, and one of
the guard inputs is a channel from a high priority process.
I’ve made an assumption in the emulator that ALL instructions can be
interrupted after completion for a low priority task (including Pfix
and nfix). Does this seem sensible? I believe it is inline with the
Inmos data books. I know there are a couple of instructions that are
interruptible part way through but I’m not doing this in the emulator.
What is interesting is it does happen in a couple of the btl files
I’ve run. Since I’ve put a debug message in the schedule function to
look out for the problem. It happens in the Inmos Idump.btl if run on
the emulator.
Is there some trick I’m missing or something clever that Inmos have
done in the real T414 device?
P.S. Last night I uploaded a newer jserver v2.6 executable on my
website.
Gavin Crate
> Whilst making changes to the PC based combined T414B emulator and host
> server, I've come across an interesting problem whilst debugging the high
> priority interrupt mechanism.
>
> The Problem
>
> Assume a low priority task is running. It gets interrupted since a
> high priority task needs to run (due to say a timer has become ready).
> The high priority task runs and one of its instructions requires the
> low priority (previously interrupted) to be rescheduled on the low
> priority queue.
>
> If it rescheduled the task on the low priority queue, then there would
> effectively be two occurrences of the same thread – the one
> interrupted and the one on the queue?
>
> Can the above happen on the real T414 device? My thoughts are yes, if
> the low priority task is handling an Occam ALT statement, and one of
> the guard inputs is a channel from a high priority process.
>
> I’ve made an assumption in the emulator that ALL instructions can be
> interrupted after completion for a low priority *** instruction *** (including Pfix
Gavin Crate
> Corrections below indicated by ***
Ignore it - It was correct the first time!
Gavin Crate
Firstly, the problem I outlined above can not happen in the real
Transputer. The reason why it can’t is outline below.
There is a state variable (at wptr -3) which contains enabling.p,
waiting.p or Ready.p if a process is executing the low level
instructions involved in the Occam ALT statement.
If a high priority process is started and happens to execute an
‘out’ (or outbyte or outword) instruction (say as a result of a timer
becoming ready) and it interrupts a low priority process (which
happens to be executing the instructions involved in the ALT) then
there are two possibilities:
1. The value at the low priority tasks [wptr -3] is enabling.p, in
which case the high priority task will see this and simply indicate
the channel is ready, and set [wptr -3] to ready.p before descheduling
itself.
2. The value at the low priority tasks [wptr -3] is waiting.p, in
which case the high priority task will see this and simply indicate
the channel is ready, and set [wptr -3] to ready.p, reschedule the low
priority task, before descheduling itself.
Hence, there is no way with the operation of the state variable (at
wptr -3) that the interrupted low priority task (executing the ALT
instructions) could be incorrectly rescheduled by the interrupting
high priority process executing the out instruction.
The reason it was happening in the emulator, was that the code in the
‘out’ (or outbyte or outword) instruction, was incorrectly responding
to the state stored in [wptr-3]. The emulator incorrectly assumed that
if not ready.p at [wptr-3] then it set it ready.p and scheduled the
low priority task. The code over looked that fact that [wptr-3] might
contain enabling.p, which I’ve described the correct handling above.
I will put this correction (bug fix) into the next release of the PC
based combined T414B and host server (jserver).
Mike B.
1) Please note: In the timer handling is a similarly stumbling block!
2) Interrupt after pfix/nfix:
... #25 #FD ....
What happens if your transputer-emu will be "interrupted" between #25
and #FD?
The move2dnonzero (opr 5D) was not executed, the Oreg is not saved (I
found no hints about that on a real T) and the Iptr points to #FD.
Maybe your emulator may execute a startp (opr D), which isn't
recommendable.
-Mike
Gavin Crate
> 1) Please note: In the timer handling is a similarly stumbling block!
Can you expand on this - I may have it covered in the latest version
of the emulator. Please explain in more detail what you think is a
potential problem.
> 2) Interrupt after pfix/nfix:
>
> ... #25 #FD ....
>
> What happens if your transputer-emu will be "interrupted" between #25
> and #FD?
The emulator correctly handles high priority interrupts after pfix and
nfix instructions. I've implemented a shadow OReg and not if the last
instruction before the interrupt was a nfix or pfix, and if so retain
the OReg on return else it gets set to zero.
> The move2dnonzero (opr 5D) was not executed, the Oreg is not saved (I
> found no hints about that on a real T) and the Iptr points to #FD.
> Maybe your emulator may execute a startp (opr D), which isn't
> recommendable.
The move2dnonzero is a T425 instruction and not implemented on the
T414.
As a passing point, getting the emulator to correctly handle the high
priority interrupt mechanism has been a real head ache. There are lots
of complex issues which have kept my brain busy working for months on
and off!!! In fact, this emulator debugging has been a real challenge
(worse than learning to dance) :-)
Mike B.
Between taltwt (rescheduled by a ready input) and dist (so we are in
the disabling sequence) it is not a good idea to reschedule this
process as a result of a timer event (set by taltwt) because you will
end up again with two processes.
The distinction is very probably done by the pw.State content. I think
that, because tin sets pw.State to Enabling.p. The exact mechanism is
vague. I think that all actions (out* & timer) which put a waiting
process out of (t)altwt also sets the pw.State to Ready.p (or
Disabling.p which has the same value ... ST20C2/C4 Core Instruction
Set Reference Manual). But this has to be investigated on a real
processor.
Does someone know by heart the value of pw.State after altend? Is it
always #80000003?
-Mike
Gavin Crate
>
> Between taltwt (rescheduled by a ready input) and dist (so we are in
> the disabling sequence) it is not a good idea to reschedule this
> process as a result of a timer event (set by taltwt) because you will
> end up again with two processes.
Hi Mike!
This can't happen in the jserver v2.6. When the process (Wptr_A)
(which executed the taltwt) is rescheduled by a ready input channel,
the schedule () firstly looks at [Wptr_A-3] to see if it is handling
an ALT construct and removes an existing waiting timer for Wptr_A from
the appropriate timer queue, before it adds Wprt_A to the queue (or
interrupts if its a high pri task and the existing pri is low). In the
emulator, only once an instruction has been executed does it do a
update_time (), where the timers are moved on and checked. In fact the
new jserver v2.6 now performs the update-time () for N instruction
cycles, to realistically simulate the T414B-20 instruction timing and
clocking behaviour.
Regarding the original problem - Assume a low priority task is
running. It gets interrupted since a high priority task needs to run
(due to say a timer has become ready). The high priority task runs and
one of its instructions requires the low priority (previously
interrupted) to be rescheduled on the low priority queue.
I have thought of a sequence which could result in the above
occurring.
Assume a low pri task is running. It executes a runp (with its own
wptr and high pri). This will cause the schedule () to causes an
interrupt, and the new process will start running. If this high pri
task then at some point executes another runp (with its own wptr and
low pri) this will cause the schedule () to put a task on the low pri
queue. I believe this sequence is a commonly used trick to switch proc
priority and results in the above problem to occur.
Gavin
Gavin Crate
the assumption that ALL a low priority task instructions can be
interrupted after completion (including pfix and nfix). I also said
there were a couple of instructions that are interruptible part way
through but I’m not doing this in the emulator.
This raises another interesting query which I will cover below.
Assume a low priority process is running. At some point it executes
the following sequence initiate a copy of itself as a high priority
task:
ldlp 0
runp
stopp
This sequence causes a new task to be put on the high priority queue,
and the low priority task stops (putting its Iptr in wptr -1).
The high priority process runs, executes some instructions and then at
some point wishes to switch back to low priority. It executes the
following sequence to initiate a copy of itself as a low priority
task:
ldlp 0
ldc 1
or
runp
stopp
This sequence causes a new task to be put on the low priority queue,
and the high priority task stops (putting its Iptr in wptr -1).
At some point later the low priority task (on the queue) runs and
carries on etc ...
The above is fine if you assume that the interrupt mechanism is
switched off.
HOWEVER, it you assume high priority task interrupts are enabled then
there is a big problem, which I will explain.
In the emulator, the runp instruction calls the schedule (). If a high
priority task is being put on the queue and the current executing task
is a low priority then an interrupt will occur and the high priority
task will start immediately after the low priority registers are
stored.
The problem (in this case) is that the stopp instruction does not
complete and put the Iptr in wptr -1, so I’m not sure what happens
when the high priority task starts running – oops!
Anyone any thoughts on how this is dealt with in the real Transputer?
It sort of implies that there may be some sequences of instructions
which are not directly interruptible - thoughts?
Mike B.
I can't imagine how the sequence "ldlp 0; runp; stopp" works. For my
opinion it's a misbelief.
>so I’m not sure what happens when the high priority task starts running – oops!
I think the new process fetches instructions from wptr-1. If its value
isn't well defined, the result will be disastrously.
The other direction "ldlp 0; ldc 1;or ;runp ;stopp" is conclusive
(documented and explained in the TIS-ACWG 6.7 PRI PAR).
Workspacesharing is a very delicate issue :-)
Where has you found this code sequence? In an inmos .btl?
-Mike
Gavin Crate
since there has been some confusion:
>> I've made an assumption in the emulator that ALL instructions can be
>> interrupted after completion for a low priority task (including Pfix
>> and nfix). Does this seem sensible? I believe it is inline with the
>> Inmos data books. I know there are a couple of instructions that are
>> interruptible part way through but I'm not doing this in the emulator.
Clarification: I am aware that there are some instructions that are
interruptable (due to there indeterminate execution time - linked
lists etc.). These are clearly defined in the Inmos data sheets. But
the existing emulator does not handle these any differently to other
instructions. No point.
However, the assumption is that if a low priority process is
executing, and a high priority process is added to a queue then it
will cause an interrupt to the low priority process (at the end of the
current instruction) and start executing the high pri task, without
adding it to the high pri queue.
On 25 Jan, 13:25, "Mike B." <michael_brues...@yahoo.com> wrote:
> I can't imagine how the sequence "ldlp 0; runp; stopp" works. For my
> opinion it's a misbelief.
I think you are correct. The above sequence won't work (since it will
never reach the stopp and write Iptr in wptr-1). However, instead I've
found a sequence used by Inmos (from Occam compiled code I've
disassembled using oc /zo or oc /za) to switch from a low to high
priority:
stl -1 -- Iptr.s
ldlp 0 -- Hi Wptr
runp
This will work as the Iptr is initialized before the runp instruction.
> The other direction "ldlp 0; ldc 1;or ;runp ;stopp" is conclusive
> (documented and explained in the TIS-ACWG 6.7 PRI PAR).
> Workspacesharing is a very delicate issue :-)
Agreed. I've found examples in inmos code.
Hence, the emulator is likely to be working correctly and this
explains why it is highlighting in the schedule () that a process is
being put on a low priority queue when there is same wptr already
interrupted.
So, a low priority process has been running, its executed:
stl -1
ldlp 0
runp
The runp has been seen by the schedule () as a high pri task, which
can interrupt the low pri task. The high pri task runs and then
eventually it runs:
ldlp 0
adc 1
runp
stopp
which then puts a low pri task on the queue and stops the high pri
task. The later runp (in the high to low) explains why I'm trapping a
process being put on a low priority queue when there is same wptr
already interrupted. It's quite normal.
Are there any other scenarios anyone can think of, which have not
already been discussed above?
Gavin
Mike B.
I agree with your detailed explanations and have one single
annotation:
Yes ...
stl -1 -- Iptr.s
ldlp 0 -- Hi Wptr
runp
will give you a high pri "copy" of the process, but how do you get
rid off the low pri process? It's still active. If the high copy gets
blocked (for example by an in-instruction) the low part will
potentially overwrite wptr-1!
I believe that a GENERAL switch to high priority without separating
the workspaces (maybe only a few words) will not work. IIRC Helios has
such a highpri macro with only a small offset.
People who need such a feature would be well advised to use the PRI
PAR (and omit the Q) from TIS-ACWG.
In the end - great work your jserver - and when do we get an upgrade
to a T425? :-)
-Mike
Gavin Crate
> If the high copy gets blocked (for example by an in-instruction) the low part will potentially overwrite wptr-1!
>
> I believe that a GENERAL switch to high priority without separating
> the workspaces (maybe only a few words) will not work. IIRC Helios has
> such a highpri macro with only a small offset.
I agree with your comments. I suspect that the guys at Inmos had long
discussions about this (and other things) and came up with a number of
priority switch methods. The example I took the code extract from
simply switched to high pri, captured current timer, did a 'shl'
instruction for 0xFFFFFFFF cycles, captured the timer, stored the
results of Reg A, B and C and delta time and then returned to a low
pri. So I guess in this case it was ok. I'll have to try a test case
with a out instruction and see what code is generated. I'll save that
for a rainy day! :-)
> In the end - great work your jserver - and when do we get an upgrade
> to a T425? :-)
Firstly thank you for you praise. As previously stated, I've spent
hours pouring over Juilen's original code, debugging it, sorting it
and adding various improvements over the recent couple of years. I'm
very pleased with the results and it great to see it's now starting to
behavior very closely to the real T414B. I've still got a few
outstanding bugs to track down (Minix for one - arrrgh!!!), complete
the accurate instruction cycle times (for the remaining in and out
instructions) and finish off adding the undocumented C Reg changes but
I must be on the home straight now. As for the T425, surely we can
team up and jointly develop a T800 emulator, once I finished the T414B
emulator and release the source code (when I'm happy with it). You
know you are drying to help write all those lovely floating point
arithmetic instructions!!!! ;-)
As a closing thought, I still take my hat off to Julian Highfield for
his great work (and effort) in developing the original combined T414
and host server code. A job well done.
Gavin
Gavin Crate
ago, since I was asked where I got the following (NON WORKING) low to
high priority switch code extract from:
ldlp 0
runp
stopp
It was from the following two 'old' comp.sys.transputer links. I guess
the originator's did not think the low to high priority task problem
fully through, and realise the high pri task would interrupt and stop
the stopp from executing and setting Iprt in wptr -1 ;-)
Gavin