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--