Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version VT1.00C 11/1/84; site vortex.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!sdcsvax!dcdwest!ittvax!decvax!vortex!lauren From: lauren@vortex.UUCP (Lauren Weinstein) Newsgroups: net.micro.pc Subject: Re: Speeding up the AT and PC Message-ID: <459@vortex.UUCP> Date: Wed, 5-Dec-84 19:47:13 EST Article-I.D.: vortex.459 Posted: Wed Dec 5 19:47:13 1984 Date-Received: Sat, 8-Dec-84 04:50:50 EST References: <105@sdcc13.UUCP> Organization: Vortex Technology, Los Angeles Lines: 24 The timing problem is not so simple. Dealing with the diffs between the AT and PC are easy -- you just have an environment variable specifying the machine type. But you can't really rely on the interrupt timer either. Some "look-alikes" are running it off the main system clock, which means it gets changed along with all the other system timing. But even worse, functions that, for example, are checking for input from a com line and time out after N seconds if there isn't any, often involve much more code than the simple call to check the interval timer. That code is part of the timing process, and can't even be expected to behave in a linear fashion in all cases with clock changes. The bottom line is that you pretty well have to tweak up timing functions to work on a particular machine if you need other than rather gross timings. Any software that tried to directly use the interval timer in a multi-tasking environment would probably be in even worse shape, since the OS itself would probably be using various parts of the timer for its own internal uses. That's why such OS's would typically provide "sleep" calls for programs to use to avoid such problems. But I'm not talking about multi-tasking now, just the normal single-task situation. --Lauren--