In a message on 08-19-94, Louis Rizzuto said to All:

LR>So what is VX Works?  I know UNIX can be tuned to handle Real-Time
LR>applications but can OS/2 be tuned to handle Real-Time apps.  Can
LR>either be done without the source for either operating system? 
  :
Don't know much about VxWorks.  OS/2 can only be used for "soft" realtime
applications, but that may suit your client just fine.  The main problem
is that OS/2 only guarantees an interrupt latency of 400 us or better, and
a thread dispatch delay of up to 6 ms.  To achieve these you may have to
disable swapping, too, but I don't know.  Forget about getting source for
OS/2 at this point in time.  Maybe in three years when the Mach 3.0
microkernel (WorkPlace OS) has saturated its market IBM will think about
licensing source for custom jobs, but don't count on it.

LR>Right now I don't see how anyone can, in a reliable manner, assure any
LR>client that either of these operating systems will meet their REal-Time
LR>process control needs without the very real option of modifying the
LR>operating systems involved - as necessary. 
  :
Depends entirely on what their particular definition of "realtime" is. 
This is not a term that is applied consistently.  If I correctly recall
the little bit I've heard about VxWorks, it is not at all a real-time
thing but is simply a "soft" acquisition and control product that doesn't
have very tight timing requirements.  Assuming there is a version for OS/2
or Unix (I thought it was Windows only...may be another products) it may
do just fine for your client.  Insufficient data.

LR>I think I can agree this can be done with 'C' but not with time
LR>critical systems like Real-Time process control where high speeds are
LR>crucial and where memory constraints may exist.  
  :
"Time critical" and "high speeds" are not synonymous. 
You can very easily
have a realtime ("time critical") system which operates at a few hertz. 
Real-time is more concerned with determinism and guaranteeing a certain
response time to a given event.  Thus there is no inherent problem with
using C.  I agree that *some* applications would not be appropriately
coded in C, but by no means is this a general rule.  By the way, C
compilers have long ago reached the point (at least on PCs) where they are
so darn close to the speed of assembler that it makes little sense to say
C is too slow for all but a very few cases.

LR>C++ is even slower in execution times and even compilation times than
  :
Compilation time differences are negligible and, in my opinion, irrelevant
anyway.  Execution times are identical if you are not using virtual
functions.  There is no reason, if your hardware can handle it and your
requirements allow it, not to use C++ for a real-time system.  In fact,
given the complexity of most real-time systems I would suggest that a
trend towards more frequent use of C++ in realtime is a Good Thing.

LR> ... so why would anyone consider doing Real-Time work in anything but
LR> assembler?  Anyone care to share their experise, insights, etc..
  :
Because assembler is slow (to code), bug-prone, and non-portable.  The
only thing I ever code in assembler, if I have the choice, is the inner
loop of my algorithm, and the parts of my real-time kernel that *must* be
coded in assembler in any environment.  Assembler is like Asterix's magic
strength potion: extremely powerful but to be used very sparingly and only
when absolutely necessary.

Peter Hansen  ***  Engenuity Corporation  ***  Guelph, Ontario, Canada
Internet: peter.hansen{at}canrem.com    RelayNet:->CRS    FIDO:(1:229/15)
Disclaimer:  Asterix is a cartoon character, not the ASCII symbol '*'.
___
 * MR/2 * ***  Learn Esperanto, the international language.  ***
--- FidoPCB v1.5 beta-'e'