NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/realtime/1487

Internet Message Format | 1992-12-30 | 1.9 KB

Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!sol.ctr.columbia.edu!hamblin.math.byu.edu!yvax.byu.edu!cunyvm!ccvqc
Newsgroups: comp.realtime
Subject: Re: What's wrong with DOS in real-time?
Message-ID: <[e-mail]>
From: Christopher Vickery <[e-mail]>
Date: Wednesday, 30 Dec 1992 12:30:47 EST
References: <[e-mail]>
Organization: City University of New York/ University Computer Center
Lines: 25

If you use a kernel or real-time OS, the software can easily mask
any differences between processor architecture for real-time
performance.  The items to compare are the context switch and
interrupt response times.  The amount of processor state that
has to be saved/restored and the availability of special instructions
for doing so determine context switch times.  Interrupt response
time depends on amount of state, as above, plus the amount of time
that the processor is not interruptable.  The processor's instruction
set determines the amount of time the processor has to be non-
interruptable.  If an interrupt occurs on the 8086 as a divide
instruction starts, the processor will not respond for 100x as
much time as if one of the simple instructions had just started.
The real problem with trying to do real-time with DOS is that the
software disables interrupts for long periods of time.  Adding to
the woe induced by DOS itself is the possiblity that TSRs can muck
around with the interrupt enable flag at will.  There are real time
kernels and real time operating systems available for the 8086, but if
if you want to do real-time on a DOS machine, you have to use iRMX
for Windows.  That's a full-blown real-time OS that runs only on
an 80386 or above, undoubtedly too big for a small embedded app.

Somebody else can talk about the Moto chip...
-------
Christopher Vickery, Computer Science Department, Queens College (CUNY)
Flushing, NY 11367-0904  [e-mail] [phone]