software delays (was: LINT won't do your debugging for you)

John Woods john at frog.UUCP
Tue Jul 18 08:28:00 AEST 1989


In article <12724 at bloom-beacon.MIT.EDU>, scs at adam.pika.mit.edu (Steve Summit) writes:
> In article <3588 at cps3xx.UUCP> usenet at 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 at frog.UUCP, ...!mit-eddie!jfw, jfw at eddie.mit.edu
    People...How you gonna FIGURE 'em?
    Don't bother, S.L.--Just stand back and enjoy the EVOLUTIONARY PROCESS...



More information about the Comp.lang.c mailing list