gnu@hoptoad.uucp (John Gilmore) (02/27/86)
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.arpahenry@utzoo.UUCP (Henry Spencer) (03/02/86)
> ... 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. "What, nobody?" "Well, almost nobody..." Ask Apple about using a 1200-baud modem with the original Apple IIc! (Yes, I realize that (a) the skew wasn't really enough to foul up your scheme badly, and (b) your idea has merit.) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry