Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!apple!usc!csun!fedeva!premise!mirror!frog!john
From: john@frog.UUCP (John Woods)
Newsgroups: comp.lang.c
Subject: Re: software delays (was: LINT won't do your debugging for you)
Message-ID: <1640@frog.UUCP>
Date: 17 Jul 89 22:28:00 GMT
References: <713@srhqla.SR.COM> <3588@cps3xx.UUCP> <12724@bloom-beacon.MIT.EDU>
Organization: Misanthropes-R-Us
Lines: 37

In article <12724@bloom-beacon.MIT.EDU>, scs@adam.pika.mit.edu (Steve Summit) writes:
> In article <3588@cps3xx.UUCP> usenet@cps3xx.UUCP (Usenet file owner) writes:
> >When implementing some very low level code in C under MSDOS, an if
> >with a null body provides a very handy slight delay.
> Pure software constructs are one of the worst ways of trying to
> create real-time delays.  Among other things, when a faster
> processor comes along, which ought to be an unqualified
> improvement, programs stop working because the delays are no
> longer long enough.

True, but sometimes they are the only way of creating a delay (thus making
them simultaneously the worst AND the best :-).  Case in point:  our serial I/O
Processor uses the ubiquitous G*DD*MN*D 8530 SCC chip, the one that needs about
a microsecond of delay time after each operation and whose data sheets are
dusted with a virus that destroys the brains of hardware engineers, causing
them to stubbornly refuse to put that microsecond interlock in hardware.
Achieving a microsecond delay is real hard to efficiently do with programmable
hardware (since it may take well over a microsecond to set it up).  The
solution we use is this:  accesses to the SCC are followed by a macro called
STALL (as in
	scc->scw_cmd = SELECT5;
	STALL;
).  The slowest IOP version has a null STALL macro because its cycle time is
slow enough as is.  The faster IOP version uses
	#define STALL waste++
which is sufficient.  With a little cooperation from the compiler, this
can be elaborated to a noxious degree, yet requires only another ifdef in a
header file, with no change to the actual code.

Of course, some day the compiler is likely to notice that all of those
increments can be bundled up into a "waste += 32" at the end of the function
and then we'll be stuck... :-)
-- 
John Woods, Charles River Data Systems, Framingham MA, (508) 626-1101
...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu
    People...How you gonna FIGURE 'em?
    Don't bother, S.L.--Just stand back and enjoy the EVOLUTIONARY PROCESS...