Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site hoptoad.uucp
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!sun!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: net.arch,net.micro.mac,net.micro.68k
Subject: Re: timing loops, summary and proposal
Message-ID: <560@hoptoad.uucp>
Date: Thu, 27-Feb-86 02:34:23 EST
Article-I.D.: hoptoad.560
Posted: Thu Feb 27 02:34:23 1986
Date-Received: Sat, 1-Mar-86 04:11:08 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp> <2795@amdahl.UUCP> <650@oakhill.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 26
Xref: watmath net.arch:2638 net.micro.mac:4886 net.micro.68k:1523

It's clear that an MPU designer can't rely on her customers to run the
chips at a particular clock rate.  However, it's also clear that in a
specific system, a way can be found for software to know, or determine,
the clock rate and tell the MPU.  For example, in a Mac, the UART could be
set for 9600 baud and a character output in loopback mode.  1/960 second
later, the output will be done.  This will work no matter how you've souped
up the processor, since nobody is going to skew the baud rates.
Even if the system manufacturer's setting wasn't good enough (after installing
new hardware), the user could run a program that would fix the clock
rate specification for all future applications.

Given these two assumptions, two new facilities in a microprocessor could
provide precise short-duration waits:

	A small (8-bit?) clock rate register that is loadable by
	supervisor software and indicates the clock rate of the CPU (or
	its inverse)

	An instruction which delays for a specified, short, amount of
	realtime, based on the value in the clock rate register.

This costs a small register and some microcode.  It might be worth it.
It would eliminate timing loops in that microprocessor, which is what
one major manufacturer claimed to want...
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa