From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,3d3f20d31be1c33a X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,2c6139ce13be9980 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public From: Mike Stark Subject: Re: Safety-critical development in Ada and Eiffel Date: 1997/07/10 Message-ID: <33C56F97.1223@gsfc.nasa.gov>#1/1 X-Deja-AN: 256066251 References: Organization: NASA Goddard Space Flight Center -- Greenbelt, Maryland USA Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel,comp.lang.c,comp.lang.c++ Date: 1997-07-10T00:00:00+00:00 List-Id: Don Harrison wrote: > > Tucker Taft wrote: > > :and little or no use of dynamic storage allocation after > :system startup. > : > :Eiffel's dependence on dynamic storage allocation and garbage > :collection basically rules it out for most (serious) safety-critical > :applications, despite all its admittedly nice invariants and assertions. > > Both of these issues can be dealt with in Eiffel: > > 1) Dynamic storage allocation - The solution here (as in Ada) is to use > a pre-allocated memory pool for HRT parts of the system so eliminating > the need for dynamic allocation under HRT conditions. Does this "pre-allocated memory pool" mean that you will know exactly what address each object's data will reside at, or merely that you dynamically allocate memory at initialization and do not dynamically allocate after initialization is complete? My experience with flight software people here at Goddard (and it is admittedly limited) is that they are very conservative about knowing *exactly* where everything is located in memory -- they want the equivalent of a FORTRAN common block, which can be achieved in Ada (or C++, to be fair) by declaring variables of a tagged type in a package specification, e.g. package Flight_Objects is DSS1,DSS2 : aliased Digital_Sun_Sensor.Instance; -- Digital_Sun_Sensor.Instance is a tagged type in the Sensor class hierarchy -- all the types below are tagged Sun : aliased Solar_Model.Instance; Orbit : aliased Orbit_Propagator.Instance; -- etc. end Flight_Objects; (the aliased keyword in Ada allows pointers to statically declared objects) This is *not* the same thing as allocating objects at initialization -- the heap is not involved at all. > > 2) Garbage collection - This can be solved by turning memory allocation and > deallocation (GC) off after start-up. Agreed -- this is reasonable approach > > :It is not so easy to take a language like Eiffel that is fundamentally > :oriented toward dynamic storage allocation (and pervasive dynamic binding), ... > > Eiffel implementations optimise a high percentage of dynamic calls to static > ones - 80-90%? Also, since the overhead of the calling mechanism is just part > of the cost of making the call (the total cost includes execution of the body), > the resultant penalty for default dynamic binding is reduced to 5-10% - > obviously not worth getting excited over, even for HRT systems. Both Ada and Eiffel provide information to the compiler that allows optimization of dynamic calls to static ones -- this is an advantage of these 2 languages over a less rigorously typed language such as Smalltalk. However, calls to constructors and destructors are exceedingly expensive compared to other method calls, at least in our division's experiences with C++. In the interests of full disclosure, I will say my knowledge of Ada is through actual use and of Eiffel is purely academic, so I don't have the same intuition for what works in reality when you are talking about Eiffel. I very much like the ideas behind Eiffel, especially the concept of programming by contract. Despite that, my guess is that flight software people at Goddard would not look kindly on the fact that all objects must be dynamically allocated, and that this goes double for the manned space program or for the FAA's certification of airliners. I am interested in any contrary opinions, though, especially from people who actually have used Eiffel for safety critical systems. -------------------------------------------------------------------------------- Michael Stark NASA/GSFC Phone: (301) 286-5048 Code 551 Fax: (301) 286-0245 Greenbelt, MD 20771 e-mail: michael.e.stark@gsfc.nasa.gov "I don't give them hell. I tell the truth and they THINK it's hell!" Harry S. Truman --------------------------------------------------------------------------------