Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ucsfcca.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!ucsfcgl!ucsfcca!root
From: root@ucsfcca.UUCP (Computer Center)
Newsgroups: net.micro.68k
Subject: Re: timing loops
Message-ID: <447@ucsfcca.UUCP>
Date: Sat, 8-Mar-86 04:56:11 EST
Article-I.D.: ucsfcca.447
Posted: Sat Mar  8 04:56:11 1986
Date-Received: Sun, 9-Mar-86 09:15:59 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp> <6780@boring.UUCP>
Organization: UCSF Computer Center
Lines: 21

Although I haven't seen all the messages in this discussion I have
seen what appears to be a lumping together of two things which are
really different.

In the first case (and I believe this was the origin of the series)
there is the necessity of guaranteeing a minimum time between
critical events due to a latency in a hardware device. In this case,
just providing the instructions which insure this delay in the
fastest case (e.g. all caches, pipelines, etc. functioning) is
good enough. You don't care about interrupts etc. since you
certainly aren't going to allow the interrupt routine access to
the device in such a case.

The other case is opposite, i.e. guaranteeing a maximum time between
critical events. This can never be satisfied if unconstrained
interrupt processing is allowed.

The real issue worth discussing then appears to be what constraints
are sufficient and minimal to allow the requirement to be satisfied.

Thos Sumner  (...ucbvax!ucsfcgl!ucsfcca!thos)