HDTenEightyP/NetNews huggingface dataset:
From: danh@quantum.uucp (Dan Hildebrand)
Subject: Re: What's wrong with DOS in real-time?
Date: Wed, 06 Jan 93 18:17:30 GMT
Organization: Quantum Software Systems, Ltd.

In article <sT3XwB1w165w@ade.no> kai@ade.no (Kai Atle Myrvang) writes:
>> >There are Real-Time Operating Systems available for 'DOS' machines
>> >(80386/80486 PC's) which are scalable, and thus suitable for many embedded
>> >applications.  OS-9000 (a product I sell) would be one example of such an OS
>> >
>> Right.  My comment meant to indicate that the only real-time OS that runs
>> with DOS is iRMX for Windows.  Then I found out that QNX runs with DOS/
>> Windows too.
>
>Not the only two, There is a product named WinVRTX out on the market.  As 
>the name indicates, this is a VRTX and Windows environment.  Don't know too 
>much about it.  For those wanting to seek info, try Ready Systems' office 
>in France or Responsive Software Inc, Methuen, MA (USA). 

This seems to be a very popular facility for realtime systems ( and 
operating systems in general ). It would be interesting to see this table 
filled out:

OS                    DOS          Windows     Windows
(alpha order)         Support      3.0         3.1
-----------------------------------------------------------
OS-9000               Y            Y           ?
QNX                   Y            Y           Y
RMX                   Y            ?           Y
VRTX                  Y            ?           ?
UNIX (DOS/Merge)      Y            real mode   N
UNIX (VPIX)           Y            real mode   N


Some other questions worth asking are:

1) How much slower do DOS apps run than under native DOS or Windows ?

2) Does the DOS app have free access to hardware registers and interrupts ?
How much is this access slowed by the emulation ?

2) How much free memory does a DOS app see ?

3) Is there access to extended memory, expanded memory, Himem.sys, DPMI ?

4) Does Windows 3.1 run natively within as many megabytes of memory as it
wants or is it forced into a 1 Mbyte realmode environment ?

5) What IPC exists between the realtime processes and the Windows apps ? 
What about DDE ? Networking ?

6) How much does the presence of Windows impact the realtime performance of
the processes managed by the realtime OS ?

7) If the realtime OS provides a different file system, is there shared 
access between the DOS and native filesystems by the DOS/Windows and 
realtime OS ?
-- 
Dan Hildebrand                     email: danh@qnx.com
Quantum Software Systems, Ltd.     QUICS: danh  (613) 591-0934 (data)
(613) 591-0931 x204 (voice)        mail:  175 Terrence Matthews          
(613) 591-3579      (fax)                 Kanata, Ontario, Canada K2M 1W8
From: dbruce@ll.mit.edu (Dave Bruce)
Newsgroups: comp.realtime
Subject: Re: novel idea?
Date: 11 Jan 93 14:07:42 GMT
Reply-To: dbruce@ll.mit.edu (Dave Bruce)
Organization: MIT Lincoln Laboratory, Lexington MA
Originator: dbruce@ll.mit.edu (Dave Bruce)


In article <C0onL4.2qE@newcastle.ac.uk>, Adrian.Waterworth@newcastle.ac.uk (Adrian Waterworth) writes:
|> eepjm@wombat.newcastle.edu.au (Peter Moylan) writes:
|> 
|> >In article <erempel.726720401@sol.UVic.CA>, erempel@sol.UVic.CA (Evan Rempel) writes:
|> >> 
|> >> running on the side for complex graphics. If the i860 becomes
|> >> bogged down (I don't know what I would be doing to bog down the
|> >> i860, but lets say I do) and the 68040 is sitting idle (or close
|> >> to it) can one of the tasks that is running on the i860 be switched
|> >> over to the 68040 to run there.
|> >> 
|> >> i860, but if the i860 was bogged down, the net result would
|> >> be a system speedup.
|> 
|> >You must be joking.  The machine languages of these two processors
|> >are totally different.  Would you plan to run an 860 simulator on
|> >the 68040, or recompile the source code each time you switched
|> >processors?  Either way, the overheads are mind-boggling.
|> 
|> available, what's wrong with having two _pre-compiled_ versions of the
|> task (one for each processor)? The task switching problem then becomes
|> a simple case of suspending on one processor and loading/running on the
|> other. I can't think of any references straight off the top of my head,
|> but I know that this kind of technique has long been proposed (and
|> probably used by now) as a means of supporting load-balancing and
|> process migration in heterogeneous distributed systems.
|> 
|> 				Adrian.

I think the original author of this article wants the 68040 to take over
execution of a task that has been started but is being starved of cpu time.
And since the 68040 is twiddling its thumbs, it can give some help. If there
are two (or more) _pre-compiled_ versions of a task, what about the present
state of the task(s)? Globals, stacks, task allocated resources need to
transferred over to architecturely different cpu. I agree with Peter, "You
Must Be Joking!"

Just My Opinion,

Dave Bruce
dbruce@ll.mit.edu
Newsgroups: comp.realtime
From: esprit@netcom.com (Alan F. Perry)
Subject: Re: novel idea?
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
Date: Tue, 12 Jan 1993 04:11:52 GMT

In article <1993Jan11.205639.38@logica.co.uk> adrian@pluto.logica.co.uk writes:
>>>In article <erempel.726720401@sol.UVic.CA>, erempel@sol.UVic.CA (Evan Rempel) writes:
>>>> 
>>>> I am looking for an OS (real time obviously) that has the
>>>> ability to swap a task from one cpu to another. This is merely
>>>> a multiprocessing system. The catch is that I want to be
>>>> able to mix cpu's. Say a 68040 as the general, but then a i860
>>>> running on the side for complex graphics. If the i860 becomes
>>>> bogged down (I don't know what I would be doing to bog down the
>>>> i860, but lets say I do) and the 68040 is sitting idle (or close
>>>> to it) can one of the tasks that is running on the i860 be switched
>>>> over to the 68040 to run there.
>>>> 
>Have you looked into the Locus traansparent computing facility (TCF)?
>
>(Mind you, I don't know how real-time it is.)

It is not very real-time.  When I worked there, we used to joke about
Locus making 30 machines act as one.  (While some applied this line to 
filesystem and hardware access, we were talking about the response time.)

Also, it does not do what the original submittor wants.  You can only
migrate processes across the same architecture.

I can imagine a scheme where the compilers produce pseudocode and the
processors run interpreters that would do what the original submittor
wants, but it would not be too quick.

-- 
-----------------------------------+----------------------------------------
Alan F. Perry                      | "e-mail is wrecking my life"
esprit@netcom.com        (home)    |            - some random person 
allan@hakkinen.lynx.com  (work)    |              standing in San Francisco
From: kai@ade.no (Kai Atle Myrvang)
Newsgroups: comp.realtime
Subject: Re: VMEbus
Date: Mon, 11 Jan 93 08:58:34 CET
Organization: AD Elektronikk AS, Norway

mwj@se17.wg2.waii.com (Mike Johnson) writes:

> I've got a technical writer asking me what the VME in VMEbus stands for.

The origin is VersaModule Europe.

History: Motorola developed the Versabus as a advanced bus for their
68000 back in late 70's/early 80's.  It was some huge modules, used
in their EXORmacs systems.  We europeeans love eurocards, so Motorola's
dev. department ported the bus to double eurocards, what we know as the
VMEbus.  It was announced on Systems'81 in Munich.

Kai Atle

kai@ade.no (Kai Atle Myrvang)
AD Elektronikk AS, Norway    |  Keywords:  VMEbus
Phone:  Int+479 869 970      |             OS-9
Fax:    Int+479 869 920      |             VRTX
Newsgroups: comp.realtime
From: gcall@systemname.uucp (Glen Call)
Subject: Re: VMEbus
Originator: gcall@
Organization: Motorola Computer Group Marketing
Date: Mon, 11 Jan 1993 16:10:25 GMT


In article <1993Jan8.104859@se17.wg2.waii.com>, mwj@se17.wg2.waii.com (Mike Johnson) writes:
|> I've got a technical writer asking me what the VME in VMEbus stands for. I
|>suppose it's an acronym for something, but nobody here knows what. The VMEbus
|>specification we have doesn't give this information either. Anybody know?

Officially, it is not an abbreviation for anything.  Motorola had a proprietary
bus structure called VERSAbus.  VERSAbus boards were called VERSA Modules and 
were generally labled VMxx (VM03, VM04, etc.).  The story I heard in the early
1980's is that the folks in Europe wanted a smaller form factor.  It is true
that Motorola joined up with numerous other folks in the industry to initiate
development of what eventually became VME.  Did someone get cute and suffix "VM"
with "E" for European?  I don't know.  I do know that VME and VERSAbus have a
lot in common.

Glen
------------------------------------------------------------------------------
Glen Call                          Technical Marketing Systems Engineer
Motorola Computer Systems, Inc.    gcall@phx.mcd.mot.com or mcdapps!gcall
M/S DW212                          phone: (602) 438-3408
2900 S. Diablo Way                 pager: 1-602-244-3252 Pager#2818 (digital)
Tempe, AZ 85282                    FAX:   (602) 438-3534
Newsgroups: comp.realtime
From: jcavin@tsd.arlut.utexas.edu (Jerry D. Cavin)
Subject: Realtime Hardware
Organization: Applied Research Laboratories, University of Texas at Austin
Date: Mon, 11 Jan 1993 16:41:06 GMT


Is there anyone out there that have used the chip set that
implements the XTP ( eXpress Transfer Protocol )?  

I would also like to hear comments from anyone that has used 
any multi-purpose devices ( i.e.  CPU/COMM Control/Sensors on a 
chip ).

thanks,  Jerry D. Cavin

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
NOTE: Please use the following email address:
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jerry D. Cavin                 jcavin@titan.tsd.arlut.utexas.edu
Applied Research Labs                          10000 Burnet Road 
Software Systems Division                         P. O. Box 8029
University of Texas at Austin           Austin, Texas 78713-8029
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bring me a dictionary: I want to know the meaning of LIFE.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Newsgroups: comp.realtime
From: retrac@vesuvius.rice.edu (John Carter)
Subject: SUMMARY: OS Support for Real Time Computing
Originator: retrac@vesuvius.cs.rice.edu
Organization: Rice University, Houston
Date: Tue, 5 Jan 1993 22:13:19 GMT

Last week I sent out a request for suggestions for a reading list for a
seminar that I was planning to run this quarter on ``Operating Systems
Support for Real Time Computing''.  I didn't get as many responses or
suggestions for papers as I'd hoped, but I'd like to thank those of you who
took the time to respond.  Maybe this summary will encourage those of you
out there who *do* have a reading list to post it.  Without further ado,
here are the messages and suggestions that I received.

-------------------------------------------------------------------------

From: shu@cs.purdue.edu (Lih-Chyun S Shu)

My area is in concurrency control and scheduling for hard real-time systems.
The annual IEEE Real-Time system symposium is considered the best conference
in this field. Journal of Real-Time Systems is the journal dedicated to
publishing state-of-the-art results on RTS.

-------------------------------------------------------------------------

From: dennisk@aplcenmp.apl.jhu.edu (Dennis M. Kavanagh)

An excellent recent book is Real-Time System Design and Theory
I suspect you will be deluged with references soon...

[retrac: Heh heh.  Not quite. :-)]

-------------------------------------------------------------------------

From: Christopher Vickery <CCVQC%CUNYVM.BITNET@cc.utah.edu>

I have a book titled "Real-Time and Systems Programming Featuring the iRMX
for Windows Operating System" (McGraw-Hill) coming out in March or April.
It's not good on the survey of real-time issues you're looking for.  It
covers interrupt response time, context switch time, and has an introduction
to the scheduling problem.  Most of it deals with the nitty-gritty of using
iRMX.  I teach a couple of laboratory courses on systems programming based
on iRMX.  The thesis is that a real-time OS provides the application
developer with the tools to do what is normally considered to be systems
programming: concurrency, memory, and interrupt management.

-------------------------------------------------------------------------

From: rgallen@muug.mb.ca (Rennie Allen)

One paper you might want to read is "An Architectural Overview of QNX"
available at /pub/qnx-paper.ps.Z ftp.csu.ucsc.edu.  While this is written
by a Quantum employee (danh@qnx.com), it does present a good overview of
a microkernal RTOS.

-------------------------------------------------------------------------

Again, I'd like to thank the four of you for your responses.

-- 
John Carter  -*-  University of Utah  - Center for Software Science
Newsgroups: comp.realtime
From: cole@noao.edu (Lonnie Cole)
Subject: Re: novel idea?
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Date: Mon, 11 Jan 1993 21:22:59 GMT

In article <1993Jan11.065941.21342@leland.Stanford.EDU> kellyj@leland.Stanford.EDU (Kelly Johnson) writes:
>In article <erempel.726720401@sol.UVic.CA> erempel@sol.UVic.CA (Evan Rempel) writes:
>>I haven't read very much in the realtime environment, but I have
>>a thought about an OS that has what I think is a fairly unique
>>idea.
>>
>>I am looking for an OS (real time obviously) that has the
>>ability to swap a task from one cpu to another. This is merely
>>a multiprocessing system. The catch is that I want to be
>>able to mix cpu's. Say a 68040 as the general, but then a i860
>>running on the side for complex graphics. If the i860 becomes
>>bogged down (I don't know what I would be doing to bog down the
>>i860, but lets say I do) and the 68040 is sitting idle (or close
>>to it) can one of the tasks that is running on the i860 be switched
>>over to the 68040 to run there.
>>
>>I know that the single task on the 040 would run slower than on the
>>i860, but if the i860 was bogged down, the net result would
>>be a system speedup.
>>
>>Is there any system out there that provides this type of
>>functionality?
>>
>
>The problem with the idea is that the executable code for the 68040
>and i860 are totally different.  It is not uncommon to have a
>homogeneous multi-processor system that swaps tasks between cpu's
>for load balancing, but doing so between totally different types of
>cpu's would not be a simple task of just swapping tasks. 
>I fail to see how this could ever be done effectively.  
>Anyone else agree/disagree?
>

Why does each processor have to execute the same binary code. Suppose
that each processor had its own binary copy of the code to execute and
some mechanism to share the environment (local data, stack information
etc.) then the process is not so far fetched.

I don't think it's such a silly idea, kind of interesting.

-- 
Lonnie R. Cole                             Voice:    (602) 323-4162
National Optical Astronomy Observatories   Fax:      (602) 325-9278
P.O. Box 26732                             Internet: cole@noao.edu  
Tucson, AZ 85726                           Usenet:   ...!uunet!noao.edu!cole
Newsgroups: comp.realtime
From: heesmann@antpc.ant.uni-hannover.de (Geert-Dieter Heesmann)
Subject: Wanted: Realtime-Extension for Meridian-Ada-Compiler (DOS)
Organization: Inst. f. Allgem. Nachrichtentechnik
Date: Wed, 6 Jan 1993 10:43:08 GMT


 Good morning,

 for educational purposes we've got an Ada Compiler from Meridian.
 It runs an PCs (286, 386) with DOS. 
 Unfortunately, the smallest time interval for the DELAY-statement
 is about 54.9 ms (because of DOS). For some of our applications 
 that is too long.
 Is there an extension to the DOS-Implementation, that it makes
 possible to use shorter time intervals? Or does anybody know
 a "trick" to shorten the interval?
   
   Mit freundlichen Gruessen 
    
   Geert-Dieter Heesmann        University of Hanover
                                Institut fuer Allgemeine Nachrichtentechnik
                                Appelstr. 9a
                                W-3000 Hannover 1, Fed. Rep. of Germany
                                Tel.: +49 511 762-2836
                                Fax:  +49 511 762-3030

   **************************  E N D E  ************************************

Newsgroups: comp.realtime
From: ptr@itk.unit.no (Odd Pettersen)
Subject: RT Op. Syst. starts from MS-DOS
Keywords: RT OS, RT Kernel, RT under DOS
Organization: Norwegian Institute of Technology / SINTEF, Trondheim, Norway
Date: Wed, 6 Jan 93 13:43:09 GMT

The Real-Time Operating System ARTOS (Advanced Real Time Operating System)
is newly released, ready for wide distribution.
The PC version runs on any IBM PC compatible computer and
starts from DOS.
A short descriptive overview is available as plain ASCII (7 pages),
by ftp from jarl.itk.unit.no [or, Internet address 129.241.154.18].
Log in as anonymous and get file pub/artos-short-1.txt

Some demo programs will also be available shortly, under the same
computer and node.
Please inquire per e-mail for availability of the software and
documentation.

Sincerely,
Odd Pettersen

=======================================================
Odd Pettersen,
    Professor, Real-Time Computer Control
Norwegian Inst. of Technology
Dept. of Engineering Cybernetics
7034 Trondheim
NORWAY

phone  +47-7-594352 (office)
       +47-7-594376 (secretary)
fax    +47-7-594399 (secretary)
e-mail ptr@itk.unit.no
=======================================================
From: bill@mwca.UUCP (Bill Sheppard)
Newsgroups: comp.realtime
Subject: Re: What's wrong with DOS in real-time?
Date: 4 Jan 93 17:24:37 GMT
Organization: Microware Systems Corp., Santa Clara, Ca.

In <92365.123047CCVQC@CUNYVM.BITNET> CCVQC@CUNYVM.BITNET (Christopher Vickery) writes:

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

There are Real-Time Operating Systems available for 'DOS' machines
(80386/80486 PC's) which are scalable, and thus suitable for many embedded
applications.  OS-9000 (a product I sell) would be one example of such an OS.

Bill Sheppard
Microware Systems
-- 
 ##############################################################################
 # Bill Sheppard  --  Western Regional Sales Manager  --  bills@microware.com #
 # Microware Systems Corporation -- OS-9 / OS-9000 / CD-RTOS -- (408)980-0201 #
 ############## Opinions expressed are my own and usually wrong ###############
Newsgroups: comp.realtime
From: gillies@cs.uiuc.edu (Don Gillies)
Subject: Re: novel idea?
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
Date: Tue, 12 Jan 1993 06:26:53 GMT

Re: How to change the host processor architecture in the middle of a program.

There has been some work on "Cross-Architecture Procedure Call" (CAPC)
here at the University of Illinois (Ray Essick did finished his phd on
this in 1987 I believe).  Basically, the CAPC is a good way to make
use of a compute server.  A CAPC is a remote procedure call that pages
the stack frame over the network to the target supercomputer.  As long
as the two machines have similar byte ordering and a C compiler with
identical calling conventions (which is now standardized by ANSI, I
guess), then it is not difficult to perform the call.  The trick is to
dynamically page your address space across the network to back up
indirect pointer references...  8-) 8-) 8-)

Don Gillies - gillies@cs.uiuc.edu - University of Illinois at Urbana-Champaign
-- 



Newsgroups: comp.realtime
From: alex@vmars.tuwien.ac.at (Alexander Vrchoticky)
Subject: Re: novel idea?
Organization: Technical University Vienna, Dept. for Realtime Systems, AUSTRIA
Date: Mon, 11 Jan 1993 16:38:22 GMT

dbruce@ll.mit.edu (Dave Bruce) writes:

[about load balancing in heterogenous systems]
>[...] Globals, stacks, task allocated resources need to
>transferred over to architecturely different cpu. I agree with Peter, "You
>Must Be Joking!"

i believe this sentence was uttered numerous times when they discussed
whether it was possible to build heavier-than-air aircraft, back in the 
days of yore, when engineers had greasy hands ...

to answer the original poster's question: task migration in
heterogenous systems is *not* a novel idea, but to my knowledge it
hasn't (yet) been commercially exploited either. 

the technical problems themselves are tremendous: incompatible instructions 
sets and incompatible data representations are among the most prominent. 

some approaches solve these problems by avoiding them: they define an 
abstract machine (shades of p-code), and implement this on the various
architectures to be supported. this obviously avoids the incompatibility
problems, because, in effect, the problem of task migration in 
heterogenous systems is reduced to the (easier) problem for 
homogeneous systems. 

however, this approach will lead to seriously degraded performance if the 
abstract machine is not implemented with extreme care (and probably even
if it is). 

so, the answer is: it's possible, but, given the expenses of the necessary
investments and the market situation (in which companies have a rather,
ahem, limited interest in allowing customers to use the competition's
computers), i wouldn't expect to see commercial products using the idea.


-- 
Alexander Vrchoticky             alex@vmars.tuwien.ac.at
TU Vienna, CS/Real-Time Systems  +43/1/58801-8168
Newsgroups: comp.realtime