Odd behaviour with priority processes and ALT statments.

[Gavin Crate]

I’ve spent the last few weeks adding realistic processor cycle
instruction timing to the T414 emulator so that it correctly mimics
the behaviour of a 20MHz Transputer (i.e. 50ns instruction cycle),
with respect to timer handling.

Whilst debugging, I’ve come across a priority problem and ALT problem
in one of my test Occam code cases.

The latest version, available in my website:
http://sites.google.com/site/transputeremulator/

At present the emulator handles high priority interrupts. Such that if
a low priority process is running and a high priority process becomes
ready (i.e. time ? AFTER delay) it causes the state of the low
priority to saved (in the interrupt saved locations below 80000048)
and the high priority process runs. Once its completed, or deschedules
then the interrupted low priority process continues.

I’ve assumed that all instructions complete before interrupts occur. I
know there are a couple of instructions that are interruptable (move,
in etc.) but I’ve not handled this yet.

The question I have is – Are there any sequences of instructions that
should not be interrupted (i.e. such as the ALT setting up), since it
may likely cause odd behaviour if a single Transputer is executing
multiple high and low priority processes (which are talking to each
other via channels and ALTs)?

There was reportedly a bug (i.e. a race) in the early version of the
Transputer silicon (T414A?) and I was wondering if anyone could shed
any light.

[Mike B.]

Hi!

> the behaviour of a 20MHz Transputer (i.e. 50ns instruction cycle),
> with respect to timer handling.

I can't really imagine why the speed of the CPU relates with the timer
handling. The timer 'ticks' independently

Interesting (without slowing down the overall performance) is the
point when the 'active set' gets empty ...

> I know there are a couple of instructions that are interruptible (move,

> in etc.) but I’ve not handled this yet.

I don't think that this is necessary, because you are running in a non-
real-time paging environment. It doesn’t make sense to emulate the
reduced interrupt latency of a real transputer.

> The question I have is – Are there any sequences of instructions that
> should not be interrupted (i.e. such as the ALT setting up)

The only sequence I know is the topic we've already discussed in
'Undocumented T414 and T800 instructions' (Nov 6, 2008). NFIX & PFIX
Apart from that, I know no other sequence.

> There was reportedly a bug (i.e. a race) in the early version of the
> Transputer silicon (T414A?) and I was wondering if anyone could shed
> any light.

The T414A timer ticks at a different frequency. For more information
I've to check the exact values.

-Mike

[Mike B.]

> The T414A timer ticks at a different frequency. For more information
> I've to check the exact values.

Both the low priority timer and the high priority timer of the
transputer tick every 1.6 microseconds. The timeslice period is
1024x1.6 microseconds.

The IMS T414A has two bugs in byte input and output, a bug in the
timer and a bug in the delayed timer input.

The Halt on Error Flag is cleared every time the T414 switches from
low to high priority. It regains its old value when the low priority
process is resumed.

-Mike

[Gavin Crate]

Hi Mike,

Thanks for all the answers.

I just thought I would clarily my initial words and answer your query.

> I can't really imagine why the speed of the CPU relates with the timer
> handling. The timer 'ticks' independently

I agree that the high priority (1us) and low priority (64us) timer
clocks are independant of the processor clock (in fact they are
actually generated based on the 5MHz clock). However to ensure the
number of instructions executed closely matches the real Transputer,
(i.e. the emulated processor being run at 20MHz) then what I have done
is to increment the high priority timer every 20 instruction cycles.
The low priority timer every 1280 instruction cycles (well inpractice
every 64 times the high priority timer is incremented).

What this gives is an acurate representation of the execution rate
with respect to the timers, since I've now added the correct number of
processor cycles per instruction into the emulator.

Regarding my initial call for help, I now believe I have located the
problem in the code and hopefuly I can add a fix within the next few
days. Apart from pfix and nfix (which we have discussed previoulsy)
there is no issue with a high priority interrupts occuring during any
sequence with the instruction set as far as I can deternmine.

Gavin