Re: Not intended for use in medical devices

Re: Not intended for use in medical devices

[Robert C. Leif, Ph.D.]

To: Kaz Kylheku et al.
From: Bob Leif, Ph.D.
Ada_Med

I have very strong reservations about reviewing object code.  Although
configuration management tools could be configured to prevent changes in
the object code, I believe that there would be a very strong temptation for
some of the programmers to hand optimize the object code.  This would
result in having to maintain the object code, which would be very
expensive.  I must emphasize that the skill level of most of the readers of
Comp.Lang.Ada is much higher than that of most medical device programmers.
 The obvious proof of this statement is that most medical device software
is programmed in C or C++.  What other newsgroups do you propose posting
medical software discussions?
----------------------------------------------------------------------------
------
Kaz Kylheku wrote
Date:    Tue, 29 Apr 1997 19:34:10 GMT
From:    Kaz Kylheku <kaz@VISION.CREST.NT.COM>
Subject: Re: Not intended for use in medical,

In article <dewar.862270256@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>John said
>
><<If it were me designing life support systems for medical use I'd:
>Make use of Appendix H (Safety and Security) in Ada95.
>Review the object code.
>And then test the hell out of it like my life depended on it.>>
>
>This sounds like depending on testing too much, and on formal methods
>too little -- there is a balance sure, but the above seems unbalanced.

Reviewing the object code is (or can be) a formal method. Maybe the
use of the word ``hell'' shifts the perception of balance. :)

It's a pity that this discussion was confined to comp.lang.ada, because I
missed a lot of it, even though I sparked it with quote from the Intel
document.

Reviewing object code is important. I do it all the time, no matter what
langauge I'm using. Compiler bugs do exist; I have discovered a few in
GNU C. (just read gnu.gcc.bug over some time and you will see).
SNIP
----------------------------------------------------------------------------
---------------------

Re: Not intended for use in medical devices

[Robert Dewar]

Robert Leif says

<<I have very strong reservations about reviewing object code.  Although
configuration management tools could be configured to prevent changes in
the object code, I believe that there would be a very strong temptation for
some of the programmers to hand optimize the object code.>>


How can you possibly avoid reviewing object code for safety critical
programs? Certainly I am unaware of any acceptable methodology that
can be used today that avoids reviewing object code. I agree that we
need to develop such techn9ologies, but we are not there yet.

I think the concern about optimizing object code is misplaced. The typical
procedures followed for reviewing object code do not begin to allow for 
this kind of optimization, and I have never seen that be a problem. Indeed
usually for safety critical code, a common demand is that the compiler
NOT do any optimization (of course that is not a very well defined requirement)

Re: Not intended for use in medical devices

[Robert C. Leif, Ph.D.]

To: Prof. Robert Dewar
From: Bob Leif, Ph.D.

There are 3 levels of criticality in medical devices.  I have spent my time
on level 2 devices which were used primarily for clinical laboratory
diagnosis.  The quality of the object code was often checked as a means of
selecting a compiler.  However, I have not observed every line of object
code being scrutinized.  I do believe that a compiler code generation error
could cause a problem.  However, the probability is low, providing one puts
some care into the choice of the compiler and makes sure that it has been
tested. Of course, the easiest way to do this is to acquire a compiler that
has both been previously tested and is used by a highly skilled, vocal group.

On the other side, you mentioned optimizations. This is where I worry.
However, for purposes of performance, optimization is often needed.  I
would suggest that, where possible, Ada compiler manufacturers include the
facility to produce modified Ada source code showing what the compiler did.
 For instance, if an item is removed from a loop or a loop is unrolled,
this can be described in Ada syntax.  If the compiler eliminates uncalled
code, it could show this by annotating the listing including showing a
strike-through or similar marking.  I strongly believe that the software
should be described to humans in a manor easiest for us to understand.

For those interested in this field, I most strongly suggest that you read
Nancy Leveson's book Safeware System Safety and Computers, Addison Wesley,
1995 ISBN 0-201-11972-2. Most of you will agree with her comments on
languages, bottom of page 412 to top page 413.  Prof. Leveson emphasizes
that most mishaps are the result of systems errors. The discussion of the
Arriane rocket on Comp.Lang.Ada was a very good example of this.

One item that has been missing from Comp.Lang.Ada is any information on
device drivers for PC boards, such as analog to digital convertors. I might
add from experience, a systems engineer should consider hardware solutions
for items that are not weight nor power limited nor produced in huge
quantities.  Often, the use of hardware such as direct memory access,
fifos, and timers can greatly simplify a system.
----------------------------------------------------------------------------
-------------------------------
Date:    Sat, 3 May 1997 22:52:08 -0400
From:    Robert Dewar <dewar@MERV.CS.NYU.EDU>
Subject: Re: Not intended for use in medical devices

Robert Leif says

<<I have very strong reservations about reviewing object code.  Although
configuration management tools could be configured to prevent changes in
the object code, I believe that there would be a very strong temptation for
some of the programmers to hand optimize the object code.>>


How can you possibly avoid reviewing object code for safety critical
programs? Certainly I am unaware of any acceptable methodology that
can be used today that avoids reviewing object code. I agree that we
need to develop such techn9ologies, but we are not there yet.

I think the concern about optimizing object code is misplaced. The typical
procedures followed for reviewing object code do not begin to allow for
this kind of optimization, and I have never seen that be a problem. Indeed
usually for safety critical code, a common demand is that the compiler
NOT do any optimization (of course that is not a very well defined
requirement)
----------------------------------------------------------------------------
----------------------------------

Re: Not intended for use in medical devices

[Kaz Kylheku]

In article <3.0.32.19970504232023.006f5c8c@mail.4dcomm.com>,
Robert C. Leif, Ph.D. <rleif@RLEIF.COM> wrote:

><<I have very strong reservations about reviewing object code.  Although
>configuration management tools could be configured to prevent changes in
>the object code, I believe that there would be a very strong temptation for
>some of the programmers to hand optimize the object code.>>

This is unlikely. Perhaps if assembly language output were available from the
compiler there might be a temptation. Would such an optimization effort
go unnoticed?

Secondly, it's not clear how the review process affects the temptation. Those
programmers who are likely to be tempted into modifying assembly language or
even object code will probably carry that temptation with or without the object
code review.

At some point you have to trust that your programmers can overcome temptations.
Even if someone optimizes object code, how will that go unnoticed in an
organized project? The only way for those optimizations to become a permanent
part of the project, rather than just a patch for a single build, is if
assembly language is incorporated into the source tree.

I agree with R. Dewar: your concerns are misplaced, and don't make a good case
for avoiding inspections of the object code. In a safety critical system, an
incorrect translation of a correct program could lead to death, injury or
property damage. There is no other way to catch this sort of error except to
compile the code and then inspect the results of the translation.

In some ways, this could make somewhat of a case for using assembly language in
the first place, since in the process of reviewing object code, you have to
acquire an understanding of the program at the machine language level anyway.
I can at least appreciate where this extreme viewpoint is coming from.

How many of Ada's advantages over something like C are still relevant when you
have to inspect the object code instruction by instruction? 

Re: Not intended for use in medical devices

[Robert Dewar]

Kaz says

<<<<I agree with R. Dewar: your concerns are misplaced, and don't make a good case
for avoiding inspections of the object code. In a safety critical system, an
incorrect translation of a correct program could lead to death, injury or
property damage. There is no other way to catch this sort of error except to
compile the code and then inspect the results of the translation.>>

  I certainly agree with this. In fact I never heard of a people using a
  process for generating safety-critical code that did not require this
  kind of review, and certainly the formal standards require this.

<<In some ways, this could make somewhat of a case for using assembly language in
the first place, since in the process of reviewing object code, you have to
acquire an understanding of the program at the machine language level anyway.
I can at least appreciate where this extreme viewpoint is coming from.>>

  I strongly disagree with this, and find it surprising that anyone would
  suggest this. The review of the object code is just one of many aspects
  of the total methodology required for safety critical code. Another
  important aspect is more emphasis on the use of formal methods in
  developing and analyzing the code at a high level, and these are
  very much language dependent, and make assembly language quite useless.

  The object code review is oriented to making sure that the code reflects
  the high level intent correctly, and the objectives used in analyzing
  this code are directly derived from the original high level code. This
  is why Annex H in the RM requires Ada compilers to provide assistance
  in correlating the object output to the source (see annex H if you have
  not read it!)

How many of Ada's advantages over something like C are still relevant when you
have to inspect the object code instruction by instruction?

  All of them, and in fact they are probably more relevant than in other
  domains. Eliminating all possibilities of error from a program is 
  achieved by a layered approach, and the help that an Ada compiler
  gives in smoking out typing errors etc, and the help that the high
  level Ada semantics give in forumulating appropriate conditions for
  verification etc are of *especially* important value in SC systems.

  Also, see annex H which is oriented towards requiring that Ada tools
  have suitable facilities. For example, a validated C compiler may not
  even have a capability at all for examining the generated assembly code.
  But a 100% conforming Ada compiler (including conformance to Annex H)
  MUST have such a capability. For example, the -S and -g switches in
  GNAT that generate assembly language annotated with source line and
  label information is not just a nice-to-have feature in the context
  of annex H, it is a *required* feature.

Re: Not intended for use in medical devices

[Michael F Brenner]

Two of the Bob Lief suggestions should not be lost in the length of 
the message:
   (1) computers are now finally fast enough to do source code rewriting
       as part of the optimization, and SHOULD

   (2) hardware devices should almost always be connected to software
       via memory boards, not registers or ports 

Re: Not intended for use in medical devices

[Kaz Kylheku]

In article <dewar.862916681@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>Kaz says
>
><<<<I agree with R. Dewar: your concerns are misplaced, and don't make a good case
>for avoiding inspections of the object code. In a safety critical system, an
>incorrect translation of a correct program could lead to death, injury or
>property damage. There is no other way to catch this sort of error except to
>compile the code and then inspect the results of the translation.>>
>
>  I certainly agree with this. In fact I never heard of a people using a
>  process for generating safety-critical code that did not require this
>  kind of review, and certainly the formal standards require this.
>
><<In some ways, this could make somewhat of a case for using assembly language in
>the first place, since in the process of reviewing object code, you have to
>acquire an understanding of the program at the machine language level anyway.
>I can at least appreciate where this extreme viewpoint is coming from.>>
>
>  I strongly disagree with this, and find it surprising that anyone would
>  suggest this. The review of the object code is just one of many aspects
>  of the total methodology required for safety critical code. Another
>  important aspect is more emphasis on the use of formal methods in
>  developing and analyzing the code at a high level, and these are
>  very much language dependent, and make assembly language quite useless.

I see that now. I've been thinking about this problem a lot to try to see the
object code review in its proper perspective. The scope should be verifying the
translation against the higher level specification (the Ada source program) and
only against that specification. One would not, e.g., criticize the programmer
intent in an object code review.

The higher level specification is separately tested for correctness at a
different level of abstraction, of course.  If you develop in assembly
language, then you only have one level of specification, and the object code
review has a *much* more difficult scope.

Also here is another little thought that I had: in a safety critical system, 
one way to deal with the safety issues is to identify the hazards and then
work backwards to identify scenarios in the software that could lead to the
hazards. Clearly, not every module of the code will necessarily lead to a
hazard if it contains a defect. So the object code review doesn't have to give
equal weight to weight to every instruction sequence, but should perhaps
pay extra attention to the critical code that can create a hazard.

Re: Not intended for use in medical devices

[Kaz Kylheku]

In article <5kn99d$jje@top.mitre.org>,
Michael F Brenner <mfb@mbunix.mitre.org> wrote:
>Two of the Bob Lief suggestions should not be lost in the length of 
>the message:
>   (1) computers are now finally fast enough to do source code rewriting
>       as part of the optimization, and SHOULD

Why would you care, as long as the optimization is correct?

Not all optimizations can be expressed at the source level. I'd like Bob to
humor me as to how one would express, in source code, the optimization of a
case statement that was turned into a jump table. 

>   (2) hardware devices should almost always be connected to software
>       via memory boards, not registers or ports 

So, do you agree or disagree with these suggestions? ;)

Re: Not intended for use in medical devices

[Robert Dewar]

Michael Brenner says

<<   (1) computers are now finally fast enough to do source code rewriting
       as part of the optimization, and SHOULD

   (2) hardware devices should almost always be connected to software
       via memory boards, not registers or ports>>


I really have no idea what (1) might mean. It is of course the case that
many significant optimizations cannot be represented at the source level
(e.g. register allocation, instruction scheduling), so I really do not know
what this is about.

As for (2), I don't see that. Indeed memory mapped I/O devices are tricky.
Ada programmers in particular are tempted to speak to memory mapped I/O
devices by using address clauses, and this almost always results in subtly
non-portable code that is making unjustified assumptions.

For example, one of our large customers porting a big program wrote

    type x is array (1 .. 32) of Boolean;
    pragma Pack (x);

    vx : x;
    for vx use at .... 

    ...

    m := vx(3);

and was most distressed that the compiler issued a byte read for the
appropriate byte, rather than a word read, as required by their hardware
(which did not recognize a byte read, and blew up).

For another delicate example of the dangers of memory mapped access.
Consider running the above program using old Alsys technology. Well

a reference to vx(3) would work fine (doing a read just of that byte or
word), but if you do

   m : boolean renames vx(3);

now m is stored as a dynamic bit address, and an access to me will result
in reading bytes surrounding the original four bytes -- perfectly valid
Ada (though not very efficient), but of course disastrous in this context.

Robert Dewar
Ada Core Technologies

Re: Not intended for use in medical devices

[Matthew Heaney]

In article <dewar.863006367@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:


>As for (2), I don't see that. Indeed memory mapped I/O devices are tricky.
>Ada programmers in particular are tempted to speak to memory mapped I/O
>devices by using address clauses, and this almost always results in subtly
>non-portable code that is making unjustified assumptions.

Is there some _other_ way of doing memory I/O - without using address
clauses?  Isn't memory-mapped I/O in fact the _reason_ for address clauses
in the language?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Not intended for use in medical devices

[Robert Dewar]

Matthew Heaney said

<<Is there some _other_ way of doing memory I/O - without using address
clauses?  Isn't memory-mapped I/O in fact the _reason_ for address clauses
in the language?>>

The safest way to do memory mapped I/O is to create appropriate
abstractions, and then program them up using machine insertions so
you get *exactly* the instructions you know you need. If you have
a friendly Ada compiler that implements machine intrinsics and
inlining in an effective manner (GNAT meets these requirements for
example), then you do not introduce an efficiency penalty by doing
this, and you KNOW exactly what you are getting.

There are cases where the use of address clauses for memory mapped I/O
make sense, a notable example is in mapping into the display buffer on
the original IBM/PC. On the other hand, if you did this, without
introducing an abstraction layer, you have a program that is unnecessarily
hard to port to other environments.

There are many reasons why address clauses were put in. Certainly MMIO was
one motivation, but there are others, in particular mapping into system
data structures at spsecific addresses (e.g. getting hold of the BIOS
data area on a PC).

The critical point here is that when you use address clauses for MMIO, youa
are doing something that is inherently risky, you are assuming you know,
and relying on your knowledge of, the exact way that the compiler will
generate instructions for loads and stores.

Let's give another example, suppose I have a byte that is memory mapped on
an x86

    x : character;
    for x'address use ...

    pragma Atomic (x);  -- don't forget atomic if possible, or else volatile!

now I am pretty safe in doing

    x := x + 1;

and assuming byte load/store

or am I????

A compiler aimed at the high end x86 might well decide that it is better
to keep everything in 32 bits unless specified otherwise or when space
is noticable as in arrays, so it might allocate 32 bits -- and we have
yet another surprising portability disaster.

OK, so put in the size clause, but let's change the example a bit:

   type xt is mod 2**8;
   x : xt;
   for x'address use ...
   pragma Atomic (x);
   for x'size use 8;

and after that mouthful, we write:

   if (x and 2#0100#) then ..

to test some status bit, and sure enough we get a nice byte load, which is
what the hardware requires:

but now we optimize and the program blows, why? because the optimizer now
changes this to be a test bit instruction -- and the MMIO does not expect
or react properly to this change because of some hardware peculiarity.

Bottom line, it is true that address clauses and MMIO often go nicely
together, but it is a good idea to wrap the access in inlined abstractions,
rather than let them spread around the program, if you must use this
combination.

Re: Not intended for use in medical devices

[Ken Garlington]

One comment on Dr. Dewar's discussion on object code analysis (with
which I agree): A good part of the object code analysis can (and
should be) _automated_ with appropriate tools. In particular, it
is gratifying to see that some Ada compiler vendors are starting to
include object code coverage testing tools in their products. I
would like to think that the inclusion of Annex H has helped to
promote the development of such tools in the Ada community for
safety-critical systems.

Robert Dewar wrote:
> 
> Kaz says
> 
> <<<<I agree with R. Dewar: your concerns are misplaced, and don't make a good case
> for avoiding inspections of the object code. In a safety critical system, an
> incorrect translation of a correct program could lead to death, injury or
> property damage. There is no other way to catch this sort of error except to
> compile the code and then inspect the results of the translation.>>
> 
>   I certainly agree with this. In fact I never heard of a people using a
>   process for generating safety-critical code that did not require this
>   kind of review, and certainly the formal standards require this.
> 
> <<In some ways, this could make somewhat of a case for using assembly language in
> the first place, since in the process of reviewing object code, you have to
> acquire an understanding of the program at the machine language level anyway.
> I can at least appreciate where this extreme viewpoint is coming from.>>
> 
>   I strongly disagree with this, and find it surprising that anyone would
>   suggest this. The review of the object code is just one of many aspects
>   of the total methodology required for safety critical code. Another
>   important aspect is more emphasis on the use of formal methods in
>   developing and analyzing the code at a high level, and these are
>   very much language dependent, and make assembly language quite useless.
> 
>   The object code review is oriented to making sure that the code reflects
>   the high level intent correctly, and the objectives used in analyzing
>   this code are directly derived from the original high level code. This
>   is why Annex H in the RM requires Ada compilers to provide assistance
>   in correlating the object output to the source (see annex H if you have
>   not read it!)
> 
> How many of Ada's advantages over something like C are still relevant when you
> have to inspect the object code instruction by instruction?
> 
>   All of them, and in fact they are probably more relevant than in other
>   domains. Eliminating all possibilities of error from a program is
>   achieved by a layered approach, and the help that an Ada compiler
>   gives in smoking out typing errors etc, and the help that the high
>   level Ada semantics give in forumulating appropriate conditions for
>   verification etc are of *especially* important value in SC systems.
> 
>   Also, see annex H which is oriented towards requiring that Ada tools
>   have suitable facilities. For example, a validated C compiler may not
>   even have a capability at all for examining the generated assembly code.
>   But a 100% conforming Ada compiler (including conformance to Annex H)
>   MUST have such a capability. For example, the -S and -g switches in
>   GNAT that generate assembly language annotated with source line and
>   label information is not just a nice-to-have feature in the context
>   of annex H, it is a *required* feature.

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: Not intended for use in medical devices

[Richard Kenner]

In article <dewar.863254614@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>   type xt is mod 2**8;
>   x : xt;
>   for x'address use ...
>   pragma Atomic (x);
>   for x'size use 8;
>
>and after that mouthful, we write:
>
>   if (x and 2#0100#) then ..

An even more subtle example with that same declaration is writing

	x := 0;

On a PDP-11, this will normally generate a "CLR" instruction, which
sets a location to zero.  But on most PDP-11 models, CLR first reads
the location, then sets it to zero (because all of the other
one-operand instructions read the location, so the hardware designers
took a shortcut).  If reading and writing to a memory-mapped I/O
location means very different things (relatively common, especially
back in those days), this can have very unexpected results.

(This is not hypothetical; I often made the mistake of using CLR in
assembler code when I needed to use a MOV instruction to zero some
mapped location.)

Of course, an Ada (and C!) compiler for the PDP-11 should probably
avoid using CLR on volatile memory for just this reason.