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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,59dddae4a1f01e1a X-Google-Attributes: gid103376,public From: JP Thornley Subject: Re: Need help with PowerPC/Ada and realtime tasking Date: 1996/05/30 Message-ID: <50698632wnr@diphi.demon.co.uk>#1/1 X-Deja-AN: 157673363 x-nntp-posting-host: diphi.demon.co.uk references: <1026696wnr@diphi.demon.co.uk> <122916091wnr@diphi.demon.co.uk> x-mail2news-path: relay-4.mail.demon.net!post.demon.co.uk!diphi.demon.co.uk organization: None reply-to: jpt@diphi.demon.co.uk newsgroups: comp.lang.ada Date: 1996-05-30T00:00:00+00:00 List-Id: In article: eachus@spectre.mitre.org (Robert I. Eachus) writes: > ... other validations may matter more. And the one that matters most is our own. The primary need is an acceptable level of assurance that the compiler has no code generation fault that could affect the executable code in the box. So, the starting point is a (probably) validated compiler that is known to have had a wide usage in different aplications. The bug list must be stable and all the code generation bugs should be definable in terms of the Ada source constructs that may raise the bug - this is so that avoidance strategies and checking actions can be laid down to give assurance that the construct is not used (if this is not possible then a method for inspecting the executable for the error must be available). The likelihood of the discovery of new code generation faults must also be low, as the effort needed to deal with them after the start of coding could be unacceptably large. That is the starting point for our own validation activities - which, in the past, have been based around a set of test cases that use every language construct (in the subset, not the full language) in every context in which they might appear. These test cases are compiled and the object code checked for acceptability. Any anomalies found here will place further restrictions on the code (for example, with a compiler currently in use, address representation clauses in package bodies are avoided). If this still looks OK then the compiler is judged acceptable for safety-critical code. Subsequently, as the application code is produced, samples are compiled and the object code reviewed against the source to maintain confidence that the application is not going into untested areas of the compiler. Any compilation units that do not use the predefined compiler switches also have the object code inspected. If the level of effort required for the test cases is not feasible for a particular project/compiler then it is necessary to inspect 100% of the compiler output against the source. -- ------------------------------------------------------------------------ | JP Thornley EMail jpt@diphi.demon.co.uk | ------------------------------------------------------------------------