Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!rochester!ritcv!ccivax!rb
From: rb@ccivax.UUCP (rex ballard)
Newsgroups: net.arch,net.micro.68k
Subject: Re: timing loops
Message-ID: <438@ccivax.UUCP>
Date: Wed, 26-Feb-86 23:31:27 EST
Article-I.D.: ccivax.438
Posted: Wed Feb 26 23:31:27 1986
Date-Received: Sat, 1-Mar-86 17:45:07 EST
References: <156@motatl.UUCP>
Reply-To: rb@ccivax.UUCP (What's in a name ?)
Organization: CCI Telephony Systems Group,  Rochester NY
Lines: 19
Xref: watmath net.arch:2656 net.micro.68k:1527
Summary: A good idea for next chip.

What is really needed is a standard "time base" signal that is
independent of "Chip Clock" speed.  When Chip makers create a "wait X"
instruction where X is the time in microseconds, and put the neccessary
loop/wait in the micro-code, I will be GLAD to stop using loops.  I have
always hated them (bursty DMA can blow timing too).  Something is
needed for that little window that is smaller than the RTC interrupt,
and bigger than a NOP or wait state.  Even a constant period NOP would
be nice.

With the 68020, even the old trick of running a big loop and timing
it against the RTC chip doesn't work (cache misses in shorter loops).

There are still a few places where very short timing intervals are
still needed, and have to be reasonably accurate.  Things like
hand-shaking, line-turnaround, device locking (where TAS won't do,
or needs to be done more than once).

The original point of using them for copy-protection schemes and
long trivial loops is valid.  Don't do it.