VxWorks vs. RTEMS

[gregory.menke at gsfc.nasa.gov]

"Joel Sherrill <joel at OARcorp.com>" <joel.sherrill at OARcorp.com> writes:
 > Jack Cawkwell wrote:
 > > gregory.menke at gsfc.nasa.gov on Monday, August 9, 2004 at 4:22 AM  wrote:

 > >>>One of the reasons that vxWorks and RTEMS are so
 > >>>much faster than conventional operating systems is 
 > >>>they don't have to spend time fooling around with vm
 > >>>hardware whenever a context switch occurs- thats the
 > >>>tradeoff you make; speed vs protection. 
 > > 
 > > ...
 > > 
 > > Slightly off the topic: is this important in life 
 > > critical applications? Would authorities approving 
 > > critical systems be happier, or even insist on, using 
 > > hardware context switching, for reasons of safety?
 > 
 > Just to make sure it isn't getting confused in the
 > discussion, there is no special hardware assistance
 > for the context switch.  For a non-VM OS like RTEMS,
 > we switch the registers that are potentially
 > modified by the application under the standard
 > calling convention for the CPU.  When you add
 > thread/process specific memory protection with or
 > without backing store, you just end up having to
 > switch more context.  Now the MMU is part of the
 > context.  So it is just more complex.
 > 

Some time ago we evaluated a processor as an alternative to the
Mongoose.  It was originally designed to execute ADA code natively-
I'm not quite sure what that means, however the processor was designed
with a number of register banks (about 15 or so IIRC) that application
software could switch between.  Each register bank maintained all the
integer and fp state.  The idea was to run one thread in each bank of
registers, then the context switch only involves selecting which bank
was to be current.  On the other hand, if you wanted more than 15 or
so tasks, then you're right back into the same old problem of saving
and restoring context.  We ended up not selecting it because we have a
lot of experience with the Mongoose and there were only a few missions
left where processors of this generation were competitive.

WRT critical systems, we address it by doing line-by-line code reviews
of the OS and application software, and employing extensive test
suites ranging from code analysis tools down to writing code included
in the application software that specifically triggers all exceptions
the hardware can issue and tests how they're handled.  Even that can't
find all the bugs- theres always unforseen combinations of
circumstances to trip you up.  But at least you can have a good chance
of failing safe.

Gregm