Performance Ada and C, was Re: Size code Ada and C

Performance Ada and C, was Re: Size code Ada and C

[Van Snyder]

In article <dewar.899298949@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
|> 
|> But to think there is a significant difference here between C, Ada or
|> C++ is I think a delusion.
|> 

Bolek Szymanski (http://www.cs.rpi.edu/szymansk) has noticed substantial
performance differences between C and Fortran, and even more substantial
differences between C++ and Fortran, at least in plasma particle-in-cell
simulation codes.  The reason that Fortran is usually faster than C is
the reason that Ada ought to be faster:  Pointers in Fortran are more
disciplined -- no pointer arithmetic, and non-pointer thing-o's must have
the TARGET attribute to get a pointer landing on them. Barbara Ryder, from
AT&T Bell Labs (I don't know what fragment she's in now, if any) has shown
that pointer optimization in C is NP-hard, while pointer optimization in
Fortran and Ada is "only" polynomially hard.

Only loosely relatedly, Les Hatton of PR-QA in Esher, Surrey, England has
noticed that defect densities and lifetime costs of equivalent programs in
Fortran, C and Ada are roughly the same, whereas defect densities and
lifetime costs of C++ programs are roughly three times as large.

One of my colleagues reminded me of a study, for which neither of us
could remember the author, that observed that 3 out of 4 C++ projects
that are initiated are cancelled before completion.

-- 
What fraction of Americans believe   |  Van Snyder
Wrestling is real and NASA is fake?  |  vsnyder@math.jpl.nasa.gov

Re: Performance Ada and C

[Markus Kuhn]

Van Snyder wrote:
> Bolek Szymanski (http://www.cs.rpi.edu/szymansk) has noticed substantial
> performance differences between C and Fortran, and even more substantial
> differences between C++ and Fortran, at least in plasma particle-in-cell
> simulation codes.  The reason that Fortran is usually faster than C is
> the reason that Ada ought to be faster:  Pointers in Fortran are more
> disciplined -- no pointer arithmetic, and non-pointer thing-o's must have
> the TARGET attribute to get a pointer landing on them. Barbara Ryder, from
> AT&T Bell Labs (I don't know what fragment she's in now, if any) has shown
> that pointer optimization in C is NP-hard, while pointer optimization in
> Fortran and Ada is "only" polynomially hard.

I wonder whether GNAT (using a backend that was originally designed
specifically for C) can make much use of this theoretically better
optimizeability of Ada. Do you know of any performance comparisons
between GNAT and another Ada95 compilers that uses a code generator
that was right from the beginning designed for Ada?

I recently spent some time optimizing an Ada encryption routine
<http://www.cl.cam.ac.uk/~mgk25/download/serpent-ada.tar.gz>,
and while the best available C implementation
<http://www.cl.cam.ac.uk/ftp/users/rja14/serpent.tar.gz>
did 27 Mbit/s, I wasn't able to get with Ada more than
20 Mbit/s on the same processor (Pentium II, 300 MHz) using
the same compiler (gnat-3.10p).

> One of my colleagues reminded me of a study, for which neither of us
> could remember the author, that observed that 3 out of 4 C++ projects
> that are initiated are cancelled before completion.

Do you know a study that using comparable methodology tries to
determine such a number for both C++ and Ada95? Would be very
interesting ...

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Performance Ada and C

[Robert Dewar]

Markus says

<<I recently spent some time optimizing an Ada encryption routine
<http://www.cl.cam.ac.uk/~mgk25/download/serpent-ada.tar.gz>,
and while the best available C implementation
<http://www.cl.cam.ac.uk/ftp/users/rja14/serpent.tar.gz>
did 27 Mbit/s, I wasn't able to get with Ada more than
20 Mbit/s on the same processor (Pentium II, 300 MHz) using
the same compiler (gnat-3.10p).

>>


It is always possible to duplicate the object code of any C code writing
in 100% Ada using GNAT. Of course you may have to write at a lower semantic
level than you would wish.

But if you didn't close the gap, it just means you didn't use the right
approach. Most probably you were using some Ada specific feature that you
thought was equivalent to the C code when it was not, that is the most common
reason for this kind of failure. 

Of course it is also possible to write inefficient C without being very
aware
of things. For exanmle, the use of strlen can be horrible compared to the
direct reading of the bounds of an array in Ada.

So this is not something that is asymmetrical. Whether a C program or an
Ada program for the same task is faster or slower depends primarily on 
the programming style used by the programmer, and only secondarily on the
compiler.

I am always surprised how often Ada programmers have no idea of the 
consequences of what they write. By the way the -gnatdg switch in GNAT is
a useful tool in this regard.

Re: Performance Ada and C

[Markus Kuhn]

Robert Dewar wrote:
> <<I recently spent some time optimizing an Ada encryption routine
> <http://www.cl.cam.ac.uk/~mgk25/download/serpent-ada.tar.gz>,
> and while the best available C implementation
> <http://www.cl.cam.ac.uk/ftp/users/rja14/serpent.tar.gz>
> did 27 Mbit/s, I wasn't able to get with Ada more than
> 20 Mbit/s on the same processor (Pentium II, 300 MHz) using
> the same compiler (gnat-3.10p).
> 
> It is always possible to duplicate the object code of any C code writing
> in 100% Ada using GNAT. Of course you may have to write at a lower semantic
> level than you would wish.
> 
> But if you didn't close the gap, it just means you didn't use the right
> approach. Most probably you were using some Ada specific feature that you
> thought was equivalent to the C code when it was not, that is the most common
> reason for this kind of failure.

Basically the only difference is that I replaced the macros in the C
version by inline functions. Are as far as performance and optimization
are concerned, I just think of inlined functions as a sort of macros
with type checking, so this should not cause the difference.

In this type of encryption algorithm, some functions are called 30
times to fiddle around with 4 registers. In the C version, the
functions are replaced by macros and manual loop unrolling is
performed. I did the same in Ada, just that I used inline functions
instead of macros. The other difference is that while in the
C function there are 8 different macros S0 to S7, I have in Ada only
a single function S with an integer parameter 0..7 that determines
with a few ifs which of S0..S7 is executed. I had hoped (and
objdump -S output suggests this) that after inline functions are
textually substituted that the optimizer removes the statically
unaccessible other if branches. So there would not be any
difference to the C version. The time consuming part looks like

 pragma Inline(S, Tr, Keying);

 Keying(W,  0, X0, X1, X2, X3); S(0, X0, X1, X2, X3); Tr(X0, X1, X2, X3);
 Keying(W,  1, X0, X1, X2, X3); S(1, X0, X1, X2, X3); Tr(X0, X1, X2, X3);
 Keying(W,  2, X0, X1, X2, X3); S(2, X0, X1, X2, X3); Tr(X0, X1, X2, X3);
 ...
 Keying(W, 30, X0, X1, X2, X3); S(6, X0, X1, X2, X3); Tr(X0, X1, X2, X3);

> I am always surprised how often Ada programmers have no idea of the
> consequences of what they write. By the way the -gnatdg switch in GNAT is
> a useful tool in this regard.

Thanks for the hint! I guess, -gnatdg will be very helpful to get
around my uncomfortable feeling that I have with Ada being a language
where the compiler silently inserts a lot of code between the lines.
However for this purpose, -gnatdg seems to be a dump in a too
early stange. Is there also a debugging dump available for the
stage where at least some of the architecture independent optimizations
(function inlining, unaccessed code removal, common subexpression
elimination) have already been done, but where there is still
a clear relationship with the source code (e.g., where the variable
names are still used where possible). The objdump -S output
alone is rather difficult to read.

It also seems that -gnatdg does not indicate how and where the
variable length arrays that functions can return are handled and
deallocated and what compiler generated runtime checks remain, such
that I could check myself where there are potential memory leaks
lurking. The RM says in H.3.1 that pragma Reviewable code should
cause such information to be produced, but I haven't yet found
out how the information that is supposed to be produced by
pragma Reviewable is made available by gnat. Or is objdump -S
all there is at the moment to satisfy RM H.3.1?

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

Re: Performance Ada and C

[ak]

Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> writes:
> 
> Basically the only difference is that I replaced the macros in the C
> version by inline functions. Are as far as performance and optimization
> are concerned, I just think of inlined functions as a sort of macros
> with type checking, so this should not cause the difference.

At least in the C frontend inline functions are not equivalent to macros
(in contrary to the documenation). The gcc backend seems to miss several
optimizations that it does with C-style macros (mainly CSE). Also the 
register allocator (on x86) seems to have some problems with inline functions.

I assume Gnat has the same problem. 

egcs-current has a new GCSE pass that might help a bit, but there are 
still other problems (e.g. if you work with objects gcc is very bad to
keep small objects in registers if you use inline functions - it always
flushes them at the border of the inline etc.)

-Andi

P.S.: Is something like the Stepanov Benchmark available for Ada95? 

Re: Performance Ada and C

[Frank Klemm]

On Fri, 03 Jul 1998 21:26:07 +0000, Markus Kuhn <Markus.Kuhn@cl.cam.ac.uk> wrote:
>
>Basically the only difference is that I replaced the macros in the C
>version by inline functions. Are as far as performance and optimization
>are concerned, I just think of inlined functions as a sort of macros
>with type checking, so this should not cause the difference.
>
Sorry, Markus, but inline functions and macros are very different.
Generally speaking, macros are more dangerous but faster.

We have a function returning x or y whether a is equal to b or not.

int inline fn1(int a, int b, long x, long y)
  {
    return a==b ? x : y;
  }

and a macro

#define fn2(a,b,c,d)  ((a)==(b) ? (x) : (y))	/* brackets, it's only a text substitution */

A function call of fn1 generates the following code:

c = fn1(expr1,expr2,expr3,expr4);

calc expr4 and store it to a register d1	-- 1 reg in use
calc expr3 and store it to a register d2	-- 2 regs in use
calc expr2 and store it to a register d3	-- 3 regs in use
calc expr1 and comprare it with d3
if equal goto lbl1
store d1 to the accu
goto lbl2

lbl1:
store d2 to the accu
lbl2:
store accu to c

A macro call of fn2 generates the following code:

calc expr2 and store it to a register d3	-- 1 reg in use
calc expr1 and comprare it with d3
if equal goto lbl1
calc expr4 and store it to the accu
goto lbl2

lbl1:
calc expr3 and store it to the accu
lbl2:
store accu to c

Problems of the inline version:
  * early evaluation of expression => needs more registers
    or a very heavy optimizer
  * evaluation of unused parameters (this is guaranteed !!!)

Tested with several C/C++-Compilers (Turbo-C++, ZTC++, WC++).


Another impressive example is:

unsigned inline sl2(int x, unsigned t1, unsigned t2)
  {
    return x ? t1 : t2;
  }

#define sl1(x,t1,t2) ((x)?(t1):(t2))

int main(void)
  {
    printf("Calling fn1... \n");
    printf("%u\n",sl1(1,sleep(1),sleep(100)));
    printf("Calling fn2... \n");
    printf("%u\n",sl2(1,sleep(1),sleep(100)));
    return 0;
  }

-- 
Frank Klemm

 /------\  /-----------------------------------------------------\
| eMail: || pfk@uni-jena.de | home: pfk@schnecke.offl.uni-jena.de |
| Tel:   ||                 | home: +49 (3641) 390545             |
| sMail: ||  Frank Klemm, Ziegesarstr. 1, D-07747 Jena, Germany   |
 \------/  \-----------------------------------------------------/

Re: Performance Ada and C

[Daren Scot Wilson]

> 
> Generally speaking, macros are more dangerous but faster.

Amazing!  And I was trying to speed up and improve some C++ programs by
converting macros to inline, along with other improvements, but I could
be shooting myself in the foot!  

-- 

Daren Scot Wilson
Member, ACM
darenw@pipeline.com
www.newcolor.com
---------------------------
"If we aren't supposed to eat animals, why are they made of meat?" 
                                            -- unknown

Re: Ariane 5 failure (Was: Size code Ada and C)

[Jean-Pierre Rosen]

John McCabe a �crit dans le message <6nfp0v$dgl@gcsin3.geccs.gecm.com>...
>dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
>>... it would be nice to have a clear answer.
>
>It certainly would.
>
>>Certainly my impression was that it would have been FAR less harmful
>>to simply get the wrong result in this code, than to generate the
>>improperly handled exception.
>
>Given the application and the circumstances, I can't see that it would
>really have made any difference in the end. As the information produced
>by the SRI was (inappropriately as it turned out) being used to direct
>the launcher, the chances are that getting a wrong answer would simply
>have resulted in the vehicle being directed in another wrong direction
>from which there would likely have been no possible means of recovery.
>

Not at all ! The information produced by the SRI was *discarded* (since it
should not even have been running at that point). However, when it failed,
the core dump was directed to the data bus...
--
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
      Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Ariane 5 failure (Was: Size code Ada and C)

[robin]

William Clodius <wclodius@lanl.gov> writes:

	>robin wrote:
	>> <snip>
	>> It's never a good idea in a real-time system to
	>> avoid run-time checks.  A run-time check on the magnitude
	>> would have caught the error and would not have caused
	>> the total failure of Ariane 5.
	>> <snip>

	>But an implicit runtime check on the magnitude did catch the error.


You're stretching the meaning of run-time check a bit.

The report called it an "unchecked conversion".

By "run-time check" I mean a specific test in the code.

The interrupt was trapped by the OS, which then shut down the
SRI computer.

	> It
	>was the way the error was handled when caught, by turning off the
	>computer(s), that caused the Ariane 5 to fail so rapidly.

No, it was the unchecked conversion.  If the conversion
had undergone a magnitude check, the OS would have never
shut down the SRI.  Any kind of error would cause the
SRI computer to shut down.  Thus, the programmer should
have undertaken every proecaution to ensire that each and
every possible cause of an interrupt could not occur.

Nevertheless, it was foolosh not to include
some fail-safe mechanism to trap any unexpected interrupts.
Miss one, and it was sudden death to the mission.

	> It was not
	>clear to me that not handling the error in this case would have caused
	>problems, because the software where the error occurred was intended for
	>prelaunch (and early launch?) analysis and control and was not clearly
	>useful for the operation of the system at the time the error occurred
	>(tens of seconds into launch).

	>William B. Clodius		Phone: (505)-665-9370

Re: Ariane 5 failure (Was: Size code Ada and C)

[William Clodius]

robin wrote:
> <snip>
> No, it was the unchecked conversion.  If the conversion
> had undergone a magnitude check, the OS would have never
> shut down the SRI.  Any kind of error would cause the
> SRI computer to shut down.  Thus, the programmer should
> have undertaken every proecaution to ensire that each and
> every possible cause of an interrupt could not occur.
> <snip>

Your reasoning might be valid if the programmers were unaware that Ada's
default semantics would cause an exception to be thrown and that this
would shut down the computer. The papers indicate that programmers did
not include an explicit check because they were aware of the semantics
and its consequences and made the decision that if the "error" would
occur it was cause for shutting down the computer. Quoting the report

"To determine the vulnerability of unprotected code, an analysis was
performed on every operation which could give rise to an exception,
including an Operand Error. In particular, the conversion of floating
point values to integers was analysed and operations involving seven
variables were at risk of leading to an Operand Error. This led to
protection being added to four of the variables, evidence of which
appears in the Ada code. However, three of the variables were left
unprotected. No reference to justification of this decision was found
directly in the source code. Given the large amount of documentation
associated with any industrial application, the assumption, although
agreed, was essentially obscured, though not deliberately, from any
external review.

The reason for the three remaining variables, including the one denoting
horizontal bias, being unprotected was that further reasoning indicated
that they were either physically limited or that there was a large
margin of safety, a reasoning which in the case of the variable BH
turned out to be faulty. It is important to note that the decision to
protect certain variables but not others was taken jointly by project
partners at several contractual levels."
...
"The specification of the exception-handling mechanism also contributed
to the failure. In the event of any kind of exception, the system
specification stated that: the failure should be indicated on the
databus, the failure context should be stored in an EEPROM memory (which
was recovered and read out for Ariane 501), and finally, the SRI
processor should be shut down.

It was the decision to cease the processor operation which finally
proved fatal. Restart is not feasible since attitude is too difficult to
re-calculate after a processor shutdown; therefore the Inertial
Reference System becomes useless. The reason behind this drastic action
lies in the culture within the Ariane programme of only addressing
random hardware failures. From this point of view exception - or error -
handling mechanisms are designed for a random hardware failure which can
quite rationally be handled by a backup system."

The assumptions given in the second paragraph were valid for Ariane 4
but not Ariane 5. The resulting turn off of the computer was not
required Ada by exception handling, but an explicit decision of the
Ariane team driven by the culture of the Ariane team.

To emphasize, the team made an explicit decision that any unhandled
exception that occurred was evidence of a hardware error and
justification for turning off the computer. They examined the code for
possible overflows that could trigger such exceptions, found this
specific part of the code, and determined that overflows for this
quantity were not physically possible and hence indicative (for the
Ariane 4) of a hardware failure. They apparently made the decision
several times not to handle this specific exception AND wWERE AWARE OF
THE CONSEQUENCES OF NOT HANDLING AN EXCEPTION. Even in the absence of a
language defined exception handling, their reasoning (culture) likely
would have caused them to explicitly insert the check and have it set a
flag which would turn off the computer at a lower level.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Plenty of unnecessary contraint tests (Was: Size code Ada and C)

[Frank Klemm]

robin wrote:
> <snip>
> It's never a good idea in a real-time system to
> avoid run-time checks.  A run-time check on the magnitude
> would have caught the error and would not have caused
> the total failure of Ariane 5.
> <snip>
>
Ada was designed to make it possible to do range checking.

Array index boundary checking is always a good idea, because out-of-boundary
write access is a very bad idea.

Arithmetic boundary checking is problem depending, it is dangerous on
arbitrary set boundaries (i.e. balance of an checking account for non
commercian usage: range -99_999.99 .. 999_999.99).

So on the security point of view array index checking should be always on.

Now another problem. Boundary checks cost CPU time. This CPU time can be
minimized. So I tested the behaviour of gnat. The main problem of gnat is, that the 
compiler do test the ranges of a value every time it needs this value.
That's a very time consumpting behaviour.

1. problem: unneccesary tests
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Every variable need an internal boundary attribute to determine
   possible ranges of a variable to avoid this.

=========================================================================   
procedure a1 is

  j : integer range 1..10;
  s : integer;
  
begin

  s := 0;
  for i in 0 .. 9 loop
    j := i + 1;
    ...
  end loop;

end a1;
==========================================================================
	xorl %ecx,%ecx
	xorl %edx,%edx
	.align 4
.L5:
	incl %edx
	testl %edx,%edx		-- perfect nonsense
	jle .L8
	cmpl $10,%edx		-- perfect nonsense
	jle .L6
.L8:
	call __gnat_raise_constraint_error	-- never called at all
	.align 4
.L6:
        ...
	cmpl $9,%edx
	jle .L5
==========================================================================
Example was generated with -O2, 

Another example:
==========================================================================

  ...
  
  prim : array (0 .. 1_000_000) of boolean;
  
begin

  -- Initialisierung
  for i in prim'range loop
    prim(i) := true;	--  rep stosb  or  rep stosd is much more efficient
  end loop;
  
  prim(0) := false;
  prim(1) := false;
  
  -- Sieben
  for i in 0 .. 1_000 loop
    if prim(i) then	-- really unnecessary boundary test
      siebe:
        declare
          k : natural;
        begin
          k := 2*i;		-- k is > 0
          while k <= 1_000_000 loop
            prim(k) := false;	-- index test unneccesary, k *is* k<=1_000_000
            k := k + i;		-- increment
          end loop;
      end siebe;
    end if;
  end loop;
  
  -- Ausgabe
  for i in prim'range loop
    if prim(i) then		-- i *is* in range of of prim'range, no test necessary
      Put_Int(i);
      Put(" ");
    end if;
  end loop;

==========================================================================
   
I tested several examples and found out, that gnat never do such a compile
time checking for unneccesary boundray tests. Removing redundant tests
results in a speedup of 120% (x2.2) on my computer for some small programs.

You can always disable range checking in Ada, but was this the idea of Ada ???

var'cmin is in the following notation the smallest possible value, var'cmax
the largest.

Possible compile time range:

 i : integer range a..b;		-- i can only be in the range a..b;
 
 i := 12;				-- i can only be in the range 12..12;
 
 j := a + b;				-- j can only be in the range a'cmin+b'cmin..a'cmax+b'cmax
 j := c + 1;				-- j can only be in the range c'cmin+1..c'cmax+1
 
 j := nat1 * nat2;			-- j can only be in the range a'cmin*b'cmin..a'cmax*b'cmax
 k := int1 * int2;			-- if int1 and int2 can be <0 it's a little bit more difficult
 
 for i in arr'range loop		-- i can only in arr'range
 
 if i < 1000 then .... end fi;		-- for .... i must be <1000
 
 j := array[i]; ....			-- for .... i must be in array'range				
 
 if cond then a1; else a2; end fi; ....	-- for .... the variable ranges in a1 and a2 must be merged

 
2. problem: bad assembler code
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   * test of var in 0..max
   
     It will be tested, that (signed)var < 0 and (signed)var > max,
     faster is a simple test (unsigned)var > max .
   
     Why build one when you can build two for twice the price?
  
   * always jump around the exception call
   
     Extremly slow on CPUs with no jump prediction or if the jump prediction
     buffer overflows.

-- 
Frank Klemm

 /------\  /-----------------------------------------------------\
| eMail: || pfk@uni-jena.de | home: pfk@schnecke.offl.uni-jena.de |
| Tel:   ||                 | home: +49 (3641) 390545             |
| sMail: ||  Frank Klemm, Ziegesarstr. 1, D-07747 Jena, Germany   |
 \------/  \-----------------------------------------------------/

Re: Plenty of unnecessary contraint tests (Was: Size code Ada and C)

[Robert Dewar]

Frank said

<<Array index boundary checking is always a good idea, because out-of-boundary
write access is a very bad idea.
>>

No, that's wrong. If you are writing certified code in which deactivated
code is not permitted, then it may not be feasible to add such checks, and
is certainly not desirable.

Incidentally, I can't begin to duplicate the assembly output you are
getting from GNAT, but probably that is because you are using an obsolete
version.

Re: Plenty of unnecessary contraint tests (Was: Size code Ada and C)

[Frank Klemm]

On 9 Jul 1998 22:05:37 -0400, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>
>Incidentally, I can't begin to duplicate the assembly output you are
>getting from GNAT, but probably that is because you are using an obsolete
>version.
>

It's a new version I got 2 weeks ago from a ftp server referenced by
adahome. If there is any newer in the web, inform me and I will test it again.
Should I publish the full soures and the ducumented assembler output ?

$ cat bin/* lib/*/*/*/gnat1 | strings
GCC: (GNU) 2.7.2.1
GNAT Lib v3.10
GNAT Preprocessor Version 1.03 Copyright 1996 Free Software Foundation, Inc.
XREF v3.10
c3.10p (970814)XREF v3.10      GNAT Lib v3.10
d3.10p (970814)

Note, that I have added some code to prevent the optimizer from removing
code. This code was written as ... in the text.

Generally speaking a range tracking of every (local) variable is very
exhausting, but that's no reason not to do this. Gnat seems to do nothing
concerning this topic...

-- 
Frank Klemm

 /------\  /-----------------------------------------------------\
| eMail: || pfk@uni-jena.de | home: pfk@schnecke.offl.uni-jena.de |
| Tel:   ||                 | home: +49 (3641) 390545             |
| sMail: ||  Frank Klemm, Ziegesarstr. 1, D-07747 Jena, Germany   |
 \------/  \-----------------------------------------------------/

Re: Plenty of unnecessary contraint tests (Was: Size code Ada and C)

[Robert S. White]

In article <slrn6q9dnh.9o.pfk@schnecke.offl.uni-jena.de>, 
pfk@schnecke.offl.uni-jena.de says...

>You can always disable range checking in Ada, but was this the idea of Ada ???

  That is the essence of the point!  Yes you can turn off _all_ of the
extra checks of Ada if you want to or need to per final delivery
requirements.  This VIOLATES NOTHING WHATSOEVER!  Ada only gives 
you a transparent non-obtursive capability to leave checks in if you
can afford them.  If you can't so what - no Ada Thought Police are 
going to throw you in jail!

  Test early and at a low level - turn off checks if you have to per
the final delivery resource requirements.
_____________________________________________________________________
Robert S. White         -- An embedded systems software engineer
e-mail reply to reverse of ( add .'s ):  net mcleodusa shift2 r white

Re: Ariane 5 failure (Was: Size code Ada and C)

[Dale Stanbrough]

"You can always disable range checking in Ada, but was this the idea of
Ada ???"


The idea in Ada is that it gives you _more_ freedom than C. You have the 
freedom to check or not to check. The only option you have with C is to
accept array index overflows, and try and find them in the debugger.


Dale

Re: Ariane 5 failure (Was: Size code Ada and C)

[John McCabe]

Dale Stanbrough <dale@goanna.cs.rmit.edu.au> wrote:
>"You can always disable range checking in Ada, but was this the idea of
>Ada ???"

>The idea in Ada is that it gives you _more_ freedom than C. You have the 
>freedom to check or not to check.

>The only option you have with C is to accept array index overflows, and
>try and find them in the debugger.

And then what? Put in checks manually that you could have done in the 
first place? As this would be an alternative option, your suggestion 
being the only option is not quite true.

Also you have the freedom in C to put in your own checks. Certainly Ada 
is easier as it puts them in automatically for you, and will leave them 
out for you if you ask it to, but I would not agree with the suggestion 
that this functionality gives you *more freedom* than C.

(Not that I think C is better of course :-)
-- 
Best Regards
John McCabe

=====================================================================
Not necessarily my company or service providers opinions.
=====================================================================

Re: Ariane 5 failure (Was: Size code Ada and C)

[Frank Klemm]

On 10 Jul 1998 08:20:16 GMT, John McCabe <john@assen.demon.co.uk> wrote:
>Dale Stanbrough <dale@goanna.cs.rmit.edu.au> wrote:
>>"You can always disable range checking in Ada, but was this the idea of
>>Ada ???"
>
>>The idea in Ada is that it gives you _more_ freedom than C. You have the 
>>freedom to check or not to check.
>
>>The only option you have with C is to accept array index overflows, and
>>try and find them in the debugger.
>
>And then what? Put in checks manually that you could have done in the 
>first place? As this would be an alternative option, your suggestion 
>being the only option is not quite true.
>
Manually checks are *NO* checks. For those who can read C:

double x[1000];

void sinusize(double *p, size_t len)
  {
    while (len--)
      *p = sin (*p), p++;
  }


main(...)
  {
    sinusize(x, sizeof(x));
    
    return 0;
  }

Array address and length are stored independendly, i.e. it is *very* easy to make
errors in the range checking. An array must be more than a pointer to enable range checking,
C can't do this.

-- 
Frank Klemm

 /------\  /-----------------------------------------------------\
| eMail: || pfk@uni-jena.de | home: pfk@schnecke.offl.uni-jena.de |
| Tel:   ||                 | home: +49 (3641) 390545             |
| sMail: ||  Frank Klemm, Ziegesarstr. 1, D-07747 Jena, Germany   |
 \------/  \-----------------------------------------------------/

Re: Ariane 5 failure (Was: Size code Ada and C)

[Pat Rogers]

John McCabe wrote in message <6o4is0$ji5@gcsin3.geccs.gecm.com>...

<snip>
>
>Also you have the freedom in C to put in your own checks. Certainly Ada
>is easier as it puts them in automatically for you, and will leave them
>out for you if you ask it to, but I would not agree with the suggestion
>that this functionality gives you *more freedom* than C.
>
>(Not that I think C is better of course :-)


Certainly an advantage for language-defined checks is the potential for
optimization that is not possible for hand-coded checks.  For example, if we
code explicit index checks in some language, say in some C++ class, the
compiler cannot remove the check  even when a given index value does not
violate the bounds (i.e. the index value is static).  No problem for an Ada
compiler.

Re: Size code Ada and C

[John McCabe]

eachus@spectre.mitre.org (Robert I. Eachus) wrote:

>(And milliseconds later, shut down the backup as well.)

Wasn't it the hot-redundant system that actually shut down first?

-- 
Best Regards
John McCabe

=====================================================================
Not necessarily my company or service providers opinions.
=====================================================================

Re: Size code Ada and C

[Larry Elmore]

John McCabe wrote in message <6ni669$i6u@gcsin3.geccs.gecm.com>...
>eachus@spectre.mitre.org (Robert I. Eachus) wrote:
>
>>(And milliseconds later, shut down the backup as well.)
>
>Wasn't it the hot-redundant system that actually shut down first?

Yep. SRI1 (the backup) shut down 72 ms before SRI2 (why SRI1 was designated
the backup and SRI2 was the primary, I don't know).

Larry

Re: Size code Ada and C

[John McCabe]

"Larry Elmore" <ljelmore@montana.campus.mci.net> wrote:

>>Wasn't it the hot-redundant system that actually shut down first?

>Yep. SRI1 (the backup) shut down 72 ms before SRI2 (why SRI1 was
>designated the backup and SRI2 was the primary, I don't know).

Typical French e.g. la plume de ma tante => my aunt's pen.:-)

(Actually, even SRI is a prime example - Inertial Reference System)

-- 
Best Regards
John McCabe

=====================================================================
Not necessarily my company or service providers opinions.
=====================================================================

Re: Size code Ada and C

[Robert I. Eachus]

In article <6nik65$2e$1@news.campus.mci.net> "Larry Elmore" <ljelmore@montana.campus.mci.net> writes:

 > Yep. SRI1 (the backup) shut down 72 ms before SRI2 (why SRI1 was designated
 > the backup and SRI2 was the primary, I don't know).

  I don't know either.  I just assumed that SRI2 was the backup.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Size code Ada and C

[Robert I. Eachus]

In article <dewar.899298821@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

  > I am puzzled, I thought the problem derived from a constaint error 
  > that was raised by a fixed point operation ...

   There was a floating to fixed/integer conversion instruction in
hardware, that signaled a fault because the operand was out of range.
This could have been handled by a local (Ada) exception handler.
However, the decision was made that this situation could only occur
(in the Arianne 4) in the case of a hardware failure.  So the
exception was allowed to propagate to an outermost handler that
switched control to the backup and dumped state.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...