Path: utzoo!mnetor!uunet!swlabs!jack From: jack@swlabs.UUCP (Jack Bonn) Newsgroups: comp.arch Subject: Re: RISC != real-time control Message-ID: <832@swlabs.UUCP> Date: 8 May 88 13:38:06 GMT References: <1534@pt.cs.cmu.edu> Reply-To: jack@swlabs.UUCP (Jack Bonn) Organization: Software Labs, Ltd., Easton, CT Lines: 31 From article <1534@pt.cs.cmu.edu>, by schmitz@FAS.RI.CMU.EDU (Donald Schmitz): > In article <1521@pt.cs.cmu.edu> koopman@A.GP.CS.CMU.EDU (Philip Koopman) writes: > >>Real-time control programs often have a situation where only >>X microseconds are available to perform a task. ..... > > This may be straying somewhat from the original point, but what sort of > applications really have such exact timing deadlines? I have done a little > real-time motion control, .... The worst system for real time deadlines I ever worked on was one that implemented the control functions for a bottle making machine. This wasn't a bottler; it took molten glass and formed it into bottles. We had a 2.5 MHz Z-80 and a periodic interrupt whose period was 1 msec. Doesn't leave much time for background processing. The worst case was if an output to the scoop was delayed. Rather than catching the molten gob of glass in flight, it would fling it across the plant floor. If it hit anyone, it would stick to their skin and most likely result in an amputation. Since I had previously worked on central office software, this gave me a much more clear view of real time. I used to worry about what would happen if a dial tone or compelled signaling tone was delayed. Ah, the good old days. -Jack -- Jack Bonn, <> Software Labs, Ltd, Box 451, Easton CT 06612 uunet!swlabs!jack