scs@adam.pika.mit.edu (Steve Summit) (07/17/89)
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. Steve Summit scs@adam.pika.mit.edu
john@frog.UUCP (John Woods) (07/18/89)
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...
mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel) (07/23/89)
In article <1640@frog.UUCP> john@frog.UUCP (John Woods) writes: > The faster IOP version uses > #define STALL waste++ ... >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... :-) /* #define volatile /* use if non-pANS C compiler */ volatile int waste = 0; -- "Let me control a planet's oxygen supply, and I don't care who makes the laws." - GREAT CTHUHLU'S STARRY WISDOM BAND (via Roger Leroux) __ \ Tim, the Bizarre and Oddly-Dressed Enchanter \ mcdaniel@uicsrd.csrd.uiuc.edu /\ mcdaniel%uicsrd@{uxc.cso.uiuc.edu,uiuc.csnet} _/ \_ {uunet,convex,pur-ee}!uiucuxc!uicsrd!mcdaniel