CBFalconer wrote:
> Paul Keinanen wrote:
> 
>>This can be quite critical especially if the Ada users are
>>overconfident due to "it compiles, it is ready for shipping" attitude.
> 
> 
> I would expect that attitude to be less prevalent with average Ada
> programmers than with average C programmers.  The reason being that
> the Ada programmer probably has an idea why he or she is using the
> language in the first place.

"Because the DoD contract says so."

Ed

On Saturday, in article <4...@yahoo.com>
     c...@yahoo.com "CBFalconer" wrote:

>Chris Hills wrote:
>> Dave Hansen <i...@hotmail.com> writes
>>> Chris Hills <c...@phaedsys.org> wrote:
>>>
>>>> but a lot less well supported. It is effectively as dead as
>>>> Pascal. There is more Forth about than Mod2 and Pascal.
>>>
>>> A few years back, GM required the use of Modula-GM for safety-
>>> critical software, such as that in antilock braking systems. 
>>> They may still, I'm not sure.  Modula's advantages over C are
>>> widely (if not universally) recognized.
>> 
>> I think most automotive things have moved to C now.
>
>I certainly hope not.  That in itself would show gross disregard
>for safety, and could be the grounds for all sorts of lawsuits and
>punitive awards.  Ada would be more reasonable.

Which is why MISRA-C was formulated and the necessary validator tools
created and Safety level criteria to meet.

-- 
Paul Carpenter          | p...@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>;    PC Services
<http://www.gnuh8.org.uk/>;              GNU H8 & mailing list info
<http://www.badweb.org.uk/>;             For those web sites you hate

CBFalconer wrote:

> "Paul E. Bennett" wrote:
>> CBFalconer wrote:
>> 
>>>> I think most automotive things have moved to C now.
>>>
>>> I certainly hope not.  That in itself would show gross disregard
>>> for safety, and could be the grounds for all sorts of lawsuits and
>>> punitive awards.  Ada would be more reasonable.
>> 
>> Considering that there are quite well known projects, that used Ada,
>> that still failed (some in quite spectacular fashion) I would have
>> thought would have constituted sufficient evidence that the
>> proogramming language used has little to do with the final system
>> safety.
>> 
>> There are constructs in every language that, if used, are probably
>> potentially lethal in a system. What seems to be evident, though, is
> ... snip ...
> 
> Of course a language is not a panacea.  But the appropriate choice
> does avoid many errors.  How many C installations do overflow
> checking, for example.  How many check a pointer range?  These
> things can all produce fatal (in the larger sense) errors without
> warning, and the sequences leading to them are easily missed even
> by experienced programmers.  I want all the help I can get.

From my sig you will have gathered that I use Forth for most of the systems 
I design and build. Many of them are very mission critical. Yet, Forth does 
not have the incumberance of type checking, is fairly free of syntax 
(except for that which you build in yourself) and will permit you to make 
the biggest mess imagineable. However, because of the development process I 
use, the care that I take in executing that development process and the 
level of review that is incorporated within the design process I can 
readily produce fully certifiable embedded systems. I have also produced 
high integrity systems with languages other than Forth, including 
assembler, so choice of language is very little to do with the resultant 
system safety. It means that I will probably consume less system resource 
with my implementations than if I had used tools that cossset you.

Naturally, when choosing a compiler you should always verify that it 
behaves as documented and examine the output code from samples that you 
know what you would expect from the resultant. That means that many will 
choose compiler products from companies that have a proven track record of 
known good compiler writing.
 
> C has its place in critical software, but it is at the periphery,
> not at the heart.

Some of the language selection process will revolve around the availability 
of programmers with appropriate domain experience or something close to it. 
Those who develop critical systems should be aware of suitable constructs 
in their chosen language (eg the MISRA-C guidelines) and have tuned their 
checking tools to issue warnings when the code uses such constructs. Also, 
as I have stated before, reviews are so important to the development 
process (and I include testing as though it is a review - with a review of 
its own results) that missing them should be avoided at all costs.

-- 
********************************************************************
Paul E. Bennett ....................<email://p...@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>;
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************

"Paul E. Bennett" wrote:
> CBFalconer wrote:
> 
>> ... snip ...
>>
>> Of course a language is not a panacea.  But the appropriate choice
>> does avoid many errors.  How many C installations do overflow
>> checking, for example.  How many check a pointer range?  These
>> things can all produce fatal (in the larger sense) errors without
>> warning, and the sequences leading to them are easily missed even
>> by experienced programmers.  I want all the help I can get.
> 
> From my sig you will have gathered that I use Forth for most of the
> systems I design and build. Many of them are very mission critical.
> Yet, Forth does not have the incumberance of type checking, is
> fairly free of syntax (except for that which you build in yourself)
> and will permit you to make the biggest mess imagineable. However,
> because of the development process I use, the care that I take in
> executing that development process and the level of review that is
> incorporated within the design process I can readily produce fully
> certifiable embedded systems. I have also produced high integrity
> systems with languages other than Forth, including assembler, so
> choice of language is very little to do with the resultant system
> safety. It means that I will probably consume less system resource
> with my implementations than if I had used tools that cossset you.

I am sure you can do so in Forth and assembly, and I can do so in C
and assembly.  But you and I are not writing that critical code for
the braking system, or the medical machinery.  Even if we were, we
are not quite as infallible as we like to think (but close).  At
the same time a well designed system will perform most checks at
compile time, and detect what run-time checks are useless, thus
approach the resource usage of the unchecked system.  Especially
when the input is generated by such paragons as you and I are, who
know what the system can and cannot catch, and act accordingly.  We
will even deliberately install "can't happen" code blocks, whose
primary purpose is to catch hardware failures, since our logical
processes are perfect by definition.

I would rather trust my code written in C than Foo Q. Bars code
written in Ada.  But I will be even more trusting of my code
written in Pascal.  In general, though, I distrust all computers
and other drivers on the road.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

Paul Carpenter wrote:
> c...@yahoo.com "CBFalconer" wrote:
>> Chris Hills wrote:
>
... snip ...
>>
>>> I think most automotive things have moved to C now.
>>
>> I certainly hope not.  That in itself would show gross disregard
>> for safety, and could be the grounds for all sorts of lawsuits
>> and punitive awards.  Ada would be more reasonable.
> 
> Which is why MISRA-C was formulated and the necessary validator
> tools created and Safety level criteria to meet.

Are you seriously suggesting that Misra-C can rival Ada in
security?  All it can do is mitigate some of the more common
failings and misuse of C.  I have never read it, since they seem to
want real money for a copy.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

In article <4...@yahoo.com>, CBFalconer
<c...@yahoo.com> writes
>Chris Hills wrote:
>> Dave Hansen <i...@hotmail.com> writes
>>> Chris Hills <c...@phaedsys.org> wrote:
>>>
>>>> but a lot less well supported. It is effectively as dead as
>>>> Pascal. There is more Forth about than Mod2 and Pascal.
>>>
>>> A few years back, GM required the use of Modula-GM for safety-
>>> critical software, such as that in antilock braking systems. 
>>> They may still, I'm not sure.  Modula's advantages over C are
>>> widely (if not universally) recognized.
>> 
>> I think most automotive things have moved to C now.
>
>I certainly hope not.  That in itself would show gross disregard
>for safety, and could be the grounds for all sorts of lawsuits and
>punitive awards.  Ada would be more reasonable.
>

Actually process is more important than language. See IEC61508

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ c...@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <4...@yahoo.com>, CBFalconer
<c...@yahoo.com> writes
>Paul Carpenter wrote:
>> c...@yahoo.com "CBFalconer" wrote:
>>> Chris Hills wrote:
>>
>... snip ...
>>>
>>>> I think most automotive things have moved to C now.
>>>
>>> I certainly hope not.  That in itself would show gross disregard
>>> for safety, and could be the grounds for all sorts of lawsuits
>>> and punitive awards.  Ada would be more reasonable.
>> 
>> Which is why MISRA-C was formulated and the necessary validator
>> tools created and Safety level criteria to meet.
>
>Are you seriously suggesting that Misra-C can rival Ada in
>security?  All it can do is mitigate some of the more common
>failings and misuse of C.  I have never read it, since they seem to
>want real money for a copy.

Since you have not read it I would suggest heresy is inadmissible.
Beside, my friend said it was perfect.

What is wrong with paying for a copy. You buy other tools I assume.

 

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ c...@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <4...@yahoo.com>, CBFalconer
<c...@yahoo.com> writes
>"Paul E. Bennett" wrote:
>> CBFalconer wrote:
>I would rather trust my code written in C than Foo Q. Bars code
>written in Ada.  But I will be even more trusting of my code
>written in Pascal. 

The implementation of the tools and the Sw Engineering process are more
important than the language.

I knew someone who said the same until we discovered his Modula 2
compiler was written (badly) in x86 assembler and the library was full
of holes.  The Modula2 system was bug written and unreliable. Of no use
for safety critical code. 

The SW process and the standard of the tools is more important than the
language.

> In general, though, I distrust all computers
>and other drivers on the road.

That seems fair enough...  I left my Horse in the car park :-)

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ c...@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Paul Keinanen <k...@sci.fi> writes:

> >Not really.  Someone has to write all the code that appears between
> >a system reset and the call to main().  
> 
> Just put the address of the init routine (written in some high level
> language) into the reset vector of the processor.

You have a lot of examples that require special additions to
compilers.  Pseudo variables for registers, init pragmas, etc.
That's a lot of effort on the compiler developers part just
because some programmers want to avoid using assembler and
inlined assembler.  Each variant of an instruction set would
need a new variant of the compiler, and maybe each RTOS would
need a compiler variant.  That could result in very expensive
compilers.  Then you'd have to learn every compilers own
idiosyncrasies since no one is going to standardize this stuff.

And I don't think it'll be all that soon before compilers can deal
efficiently with some of these issues.  The compiler writers aren't
spending their time worried about optimizing accesses to memory mapped
registers.

> >Someone has to write all the
> >stuff that inside the system libraries (and the C library). 
> 
> For current small and medium sized embedded systems with a more or
> less sensible processor architectures, there are only a few cases, in
> which larger routines really needs to be coded in assembly for
> acceptable performance.

I wasn't thinking about performance.  I was thinking about merely
having the ability to do what some OS functions need to do.  Sure, if
the compiler were tied to a specific OS then you could just use the
libraries that came with the compiler.  But normally people need to
add or modify this stuff; cache flushing routines, task switching,
instruction or IO synchronization, etc.

Sure, the compiler vendor could supply macros or functions for much of
this, but every project has slightly different requirements about how
the service libraries should work.

-- 
Darin Johnson
    Laziness is the father of invention

CBFalconer wrote:

> I am sure you can do so in Forth and assembly, and I can do so in C
> and assembly.  But you and I are not writing that critical code for
> the braking system, or the medical machinery.  

Petro-chemical process plant, Nuclear Power Stations, Railway Signalling 
and Safety Monitoring Systems, Anaesthesia Ventillators, Banking Smart 
Cards and various robotics equipment performing very critical functions 
have been in my remit. I have spent over 30 years constructing such systems 
and have always used a decent engineering process approach to achieve the 
system safety goals. So, yes I have been involved in the critical code 
generation segment. Be sure though, that there has always been a means, in 
hardware, to mitigate any remaining failures within the software. I am not 
saying that the software has ever gone wrong though (my first software, 4k 
of hand crafted machine code, ran 25 years with no failures and no need for 
modification).

Even if we were, we
> are not quite as infallible as we like to think (but close).  At
> the same time a well designed system will perform most checks at
> compile time, 

I perform most of my checks well before the code is compiled (design 
reviews, static code inspections etc). You would be amazed at how many of 
the silly errors can be found this way.

-- 
********************************************************************
Paul E. Bennett ....................<email://p...@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>;
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************