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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-31 10:16:52 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!dialin-145-254-039-076.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)) Date: Sat, 31 May 2003 19:19:19 +0200 Organization: At home Message-ID: References: <3ec4b1c9$1@news.wineasy.se> <9fa75d42.0305161748.1735fc32@posting.google.com> <4W%xa.28765$cK5.11964@nwrdny02.gnilink.net> <1053353256.804734@master.nyc.kbcfp.com> <3ECFF541.1010705@attbi.com> <3ED0B820.5050603@noplace.com> <3ED74584.1050007@noplace.com> <3ED8A3D2.2040300@noplace.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-039-076.arcor-ip.net (145.254.39.76) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1054401410 7943104 145.254.39.76 (16 [77047]) User-Agent: KNode/0.7.1 Xref: archiver1.google.com comp.lang.ada:38227 Date: 2003-05-31T19:19:19+02:00 List-Id: Marin David Condic wrote: > Interesting. And how many control systems have you built? :-) I am responsible for software design in our firm. So to say, I leave all the dirty work to others. (:-)) > I've been > doing this job for a while and the team of guys we have who do it seem > to have a consensus going that we think the *best* accommodation to take > on an overflow in our application would be to saturate the numbers. If > it is a "bad design" then it is a "bad design" that is flying around in > flight critical systems today. Because we think it is the best > accommodation for the types of faults we might encounter, we have gone > to the effort of building it ourselves. The thing is, it would be much > more convenient if we didn't have to create our own packages and cobble > it on to the side of the compiler. It would be easier to get it directly > from the compiler. So I'm talking about a feature that is already in use > and just making it more convenient for the user. You are talking about an implementation, not design. From design point of view: 1. Saturated arithmetics has no physical sense. 2. Values of different nature have to be mapped to different types. In this case you are on the safe side, not only when you send data to your DAC and have to *explicitly* convert (saturate) the value, but more importantly, when you compute the data in *normal* arithmetics with no pitfalls. 3. Better abstraction and factoring. The controlling algorithm would not depend on hardware dependent things which may change. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de