Re: waking up processes on external input

[tjoccam@xxxxxxxxxxx]

When I simulated Transputer functionality in DOS circa 1995, I was able to
get pretty good response on an 8MHz HP palmtop by doing the "primitives"
(link comms, i.e. serial, Transputer B008, and printer, and timeouts) as
interrupts using ISRs written in assembly. This worked the principle Barry
mentioned in reverse, and got pretty good response, relatively not as good
as the Transputer but far better than modern processors. The problem is
that modern OSs are designed to prevent this kind of thing. It worked in
DOS because DOS doesn't care and is completely anarchic.

Larry Dickson

> When I was at IMNOS, and this must have been before 1990, we did a
> benchmark with the T800 running its standard floating-point benchmark
> program and set "communications events" to happen every so often.
> Actually they were timer "interrupts" that did nothing, but exactly the
> same mechanism was used for both the internal channel and the external
> link communication.
>
> I forget the exact figures, but what I remember fits with Barry's under
> one microsecond. I think that when there were 500,000 (half a million)
> interrupts per second, the floating point performance reduced to about
> 50% of the performance with no interrupts. Like any benchmark, this is
> unreal, because an interupt would have to do something, but most
> processors at the time got nowhere near an order of magnitude or two of
> this.
>
> Paul Walker
> (Also 4Links)
>
> Barry Cook wrote:
>> Richard,
>>
>> It was part of the hardware.
>>
>> The low-latency from data delivery to use was a key to the
>> Transputer's high performance in multi-processor configurations.
>> Without it modern multiprocessors can't do as well - unless you
>> restrict the applications you run on them
>>
>> Input could be a data communication or an 'event'.
>>
>> If the process to be put on the queue was a high priority process then
>> the time from hardware signal to process running was below 1us.
>>
>> Event inputs, equivalent to interrupts on traditional processors,
>> causing sub-microsecond 'interrupt handler' process activation was
>> somewhat faster than interrupt response times of other processors,
>> even of today's Gigahertz-clock-rate CPU's!
>>
>>    Barry.
>>
>> Dr Barry M. Cook, BSc, PhD, CEng, MBCS, CITP, MIEEE
>> CTO,
>> 4Links Limited,
>> The Mansion,
>> Bletchley Park,
>> MK3 6ZP,
>> UK.
>> ----- Original Message ----- From: "Richard Tonge"
>> <rtonge90@xxxxxxxxxxx>
>> To: <occam-com@xxxxxxxxxx>
>> Sent: Sunday, September 24, 2006 8:23 AM
>> Subject: waking up processes on external input
>>
>>
>>> My current understanding is that on the transputer, processes were
>>> not members of the process queue when they were waiting for input
>>> from the external links. This would mean that whenever input arrived,
>>> some mechanism would have to add to the queue any process waiting on
>>> the link.
>>>
>>> Was this mechanism was part of the hardware, or was it done with a
>>> software interrupt handler?
>>>
>>> Thanks,
>>>
>>> Richard Tonge
>>> Ageia Technologies inc.
>>>
>>>
>>>
>>>
>>
>>
>
>
>