g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014 
<== Date ==> <== Thread ==>

Subject: RE: RTEMS on Diamond Systems Prometheus/ EPICS IOC on eCos
From: "Jeff Hill" <johill@lanl.gov>
To: "'Eric Norum'" <norume@aps.anl.gov>, "'Kevin S. Martin'" <ksmartin@fnal.gov>
Cc: "'EPICS Core Talk'" <core-talk@aps.anl.gov>, <tech-talk@aps.anl.gov>
Date: Fri, 10 Jun 2005 12:25:13 -0600
> Having said this, porting EPICS IOC to eCos may not be easy or even 
> possible anyway. eCos doesn't have multi-thread safe C++ Standard 
> Library support (or at least not out of the box). Is it true the IOC 
> software uses C++ STL and Exceptions?
> 

We definitely use exceptions. It's pretty hard to avoid exceptions with C++
in practice. 

O The default interface to new throws exceptions in ANSI C++, and it's
probably a good bet that someone will use that interface even if project
guidelines were to specify otherwise. 
O On some systems you get a C++ exception when there is an arithmetic fault.
O When integrating 3rd party libraries they will, more than likely, use
exceptions. 
O With C++, the only way for a constructor to fail out is by throwing an
exception.

> EPICS IOC core does not use C++ standard library routines (Jeff Hill 
> can explain why in detail -- I believe the executive summary is that 
> the standard library plays too fast and loose with memory 
> allocation/deallocation) but does require thread-safe extensions.

Our decision and intent for R3.14 was to not use the STL because, when we
started that effort, there were portability issues. We have inadvertently
introduced a small dependency on std::string resulting from use of some of
the further derived ANSI exception classes. These entanglements probably
could be eliminated simply by not throwing that type of exception class.

You can get some idea of the effort involved by looking at
epics/base/libCom/osi, and by discussing this with Eric - the author of the
RTEMS port. 

The decision should however probably be based on whether you feel prepared
to go solo. A standard disclaimer is appropriate. Software is always more
robust when there is a larger installed base. If you are the only site with
a particular OS port then if you experience an issue that no one else sees
you will not have the option of working with other sites to reproduce your
problem in order to find a fix. That means that you should have ready access
to good quality software development (debugging) tools, local system
programmer expertise (people experienced with debugging multi-threaded
programs), and a budget to cover any additional expenses.

I have no doubt that the EPICS community will benefit if you take on the
port. One advantage of multiple ports may be that OS diversity does tend to
uncover implementation problems. Assuming that these problems are fixed, the
software should be more robust to changes introduced as it evolves in the
future. Someone always has to be the first one in the pool.

There is that dilution of effort issue, but I tend to take the optimistic
view that new ports means new users who are willing to help.

Jeff



Navigate by Date:
Prev: Re: Open source Real-time Oss / open source OS Andrew Johnson
Next: RE: Open source Real-time Oss / open source OS Jeff Hill
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014 
Navigate by Thread:
Prev: RE: Open source Real-time Oss / open source OS Jeff Hill
Next: meeting in July / ca interface specification Matthias Clausen
Index: 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·