Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sauron.UUCP
Path: utzoo!linus!decvax!ittatc!dcdwest!sdcsvax!ncr-sd!ncrcae!sauron!campbell
From: campbell@sauron.UUCP (Mark Campbell)
Newsgroups: net.arch,net.micro.mac,net.micro.68k
Subject: Re: Timing loops (H/W vs. S/W design)
Message-ID: <613@sauron.UUCP>
Date: Mon, 17-Feb-86 12:07:30 EST
Article-I.D.: sauron.613
Posted: Mon Feb 17 12:07:30 1986
Date-Received: Wed, 19-Feb-86 08:11:34 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp>
Reply-To: campbell@sauron.UUCP (Mark Campbell)
Organization: NCR Corp., Advanced System Development, Columbia, SC
Lines: 61
Xref: linus net.arch:2358 net.micro.mac:4735 net.micro.68k:1431

In article <530@hoptoad.uucp> gnu@hoptoad.uucp (John Gilmore) writes:
>In article <156@motatl.UUCP>, wayne@motatl.UUCP (R.W.McGee) writes:
>> The use of software timing loops on an asyncronous
>> microprocessor should be discouraged...Public floggings would provide
>> a cure, but would be hard to implement.
>
>People who design microprocessors, who don't want software to depend
>on the timings of individual instructions in particular systems,
>should provide a system-independent way to delay for a specified
>amount of time.  We use whatever you give us, guys!
>
>E.g. in meeting the recovery time of a particularly good USART chip
>with a horrible bus interface, the Z8530, you need to wait 2.2us
>between writes to it.  Give me a good way to wait 2.2us *without*
>depending on instruction timing, and I'll consider your request.
>
>PS:  if your answer is "add more chips", a lot of people will cheap
>out and use "free" software timing loops.
>-- 
>John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa

I was going to leave this one alone until I heard the H/W developers on the
other side of the wall giggling about it.

NCR has some damned good H/W engineers; and some of the best of these work in
my division.  These guys are so good that they actually let the software drive
the architecture of a machine (what I consider the theoretical ideal, which is
seldom obtained in the "real-world").  Of course, the term "drive" implies a
high level of cooperation; however these guys really listen and make an
effort to support those hardware features that we want.  Unfortunately, there
are often constraints that cause us to miss seeing eye to eye.  As an example...

Recently, we began work on a new machine.  The very first thing the H/W guys
did was obtain a copy of "All the Chips that Fit" (by Lyon and Skudlarek, of Sun)
and proclaim that we wouldn't make the mistakes that Sun made.  The major premise
of the paper was that there were many chips that were on unfriendly terms with
Unix; and that these chips caused a great deal of pain to a Unix implementation.

Unfortunately, management then stepped in and gave us an unit price that was
terrifyingly low.  At the next review of the H/W, we suddenly found that we
were getting many of those chips, or clones of those chips, that were specifically
mentioned in the paper.  We screamed, they screamed, etc.  After digging through
the manuals, however, we found that there was very little that could be done given
their stringent constraints.  A great example was our specification of what we
now call "the mythical 32-bit, low-powered CMOS, battery-backed binary counter".
I keep getting told that a certain BCD TOD chip is really fast.  That doesn't do
me a whole hell of a lot of good when I have to use 2 or 3 pages of conversion code
to support it.

The one thing we did insist upon, though, was glue logic to support those chips
that had timing problems.  Mr. Gilmore stated that microprocessor designers should
design system independed ways of dealing with delays.  What should really happen
is that the chip manufacturers incorporate the delay logic within those chips.
The use of the term "particularly good" when referring to a device with a major
flaw such as this is a non sequiteur.  Software delay loops not only cause poor
performance (due to race conditions, interrupt latency, etc.) during porting but
usually come back to haunt you a year or two later, when you switch to cheaper
alternative sources for the devices.
-- 

Mark Campbell    Phone: (803)-791-6697     E-Mail: !ncsu!ncrcae!sauron!campbell