Certified C compilers for safety-critical embedded systems

For years the program has met some requirements that are "hidden". Users depended upon certain features but they were never called out as features in the documentation - they were useful interactions between different documented features.

A good example is the VMS Mail program, which someone decided to rewrite from Bliss into C, most likely because they favored C. Now, ten years later, they are just getting rid of the MAIL/OLD command that invoked the previous Bliss implementation. They had to carry it that long because of all the undocumented features missing from the Bliss version.

Ok, that is different.

Larry Kilgallen Who subsequently rewrote a Bliss program into Ada, knowing the lesson of VMS Mail, because the original Bliss design was incompatible with new requirements. That rewrite is just now starting to hit the streets. Wish it luck :-)

Reply to
Larry Kilgallen
Loading thread data ...

Simon Hosie:

What's that, then? About a five-year period?

Now that trading cards have gone digital, well that opens up a whole new line of non-innovation.

So... what you're saying is that money is paid to develop a new product, and then more money is paid to reduce that product to being essentially the same as all the existing products?

That's certainly a familiar story.

Reply to
Simon Hosie

In the toy industry the norm is for the inventor to develop the toy to the stage where it is presentable to the toy companies and as often as not the inventor then pays to cost reduce it.

Ian

Reply to
Ian Bell

In article , Mike Silva writes

That will change.

Praxis has a vested interest in not letting C be used for SIL 4

BTW slide 3 is erroneous. slide 5 is also erroneous.

AFAIK Praxis are not "involved" with MISRA-C they may have been some years ago in the original version but much work has been done since then. AFAIK they have not taken much, if any part, in this.

AFAIK they did not make their SPADE C results available to the MISRA-C working group who for the last 3 years have been working on MISRA-C2.

Praxis don't have a unique view of MISRA-C. They are one of many who were involved in MISRA-C1. They are not one of the main companies who were promoting and working with it in the last 5 years.

Slide 6 is interesting. The quotes are out of context and misleading. The Praxis presentation is clearly written with a (commercial) axe to grind. I was at the MISRA-C 2002 forum. In fact I did one of the presentations that has been misquoted....

As it goes on they rubbish C and surprise surprise come up with a solution that is their tools.... :-)

The Ada (tools) community must be rattled if it needs to spend time trying to rubbish MISRA-C. Perhaps it is just sour grapes as they no longer push a MISRA-C tool?

Since the 2002 meeting MISRA-C2 has been reviewed by the SAE and JSAE several major automotive companies, aerospace companies, also members of WG14 the ISO-C panel and met with approval. MISRA-C2 will be available at the end of Q1 2004

Yet C is used in some of the highest integrity systems around. Other languages that are recommended hardly exist and certainly not on many platforms.

Empirical evidence and a glance at 61508 may require a change in the table D2.... BTW table D2 in the lecturers notes is NOT in 61598.

In CEI/IEC 61508:1998 Part 7 Table C1 (page 79), yes I do have my own copy of 61508, all 7 parts. We find a similar table to "D2" above:

Sil1 Sil2 Sil3 Sil4 Ada HR HR R R ADA (subset) HR HR HR HR C R - NR NR

as expected BUT

C (subset, codinng standard and static analysis) HR HR HR HR

So whilst straight ADA *is* better than vanilla C. No one would debate that! Spark ADA is no better than C with a subset, coding standard and using static analysis.... IE much the same constraints as SPARK ADA has over ADA...

I know of projects using C in Railway, space, aero and medical projects.

PASCAL and Mod2 are mentioned but you will be hard pressed to find tool for these for many targets. BTW is there ADA for the PIC, AVR and 8015?

I come back to my comment previously that the ADA tools vendors must be worried if they are spending this much effort trying to rubbish MISRA-C which is an automotive guide. Though it has gained widespread use outside the automotive industry due to those involved with it.

Regards Chris

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

Thanks for the good analysis. I'd like to keep up with news about MISRA-C2. What's a good source?

--
Al Balmer
Balmer Consulting
 Click to see the full signature
Reply to
Alan Balmer
[...]

Nit: it's "Pascal," "Modula-2," and "Ada."

The PIC I doubt. I'm hard-pressed to consider some of the "C" compilers for PIC to be C. As an alternative HLL, JAL (Just Another Language) is kind of interesting.

formatting link

The AVR is supported by GCC, so GNAT might work, though the runtime support probably isn't there. I haven't tried it in any case.

The 8015 I've never heard of. I assume you mean 8051, to which I'd have to say I haven't heard of one, though there is a Modula-2 compiler.

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

In article , Alan Balmer writes

Well come the new year comp.lang.c.misra assuming I can get the paperwork sorted.

Otherwise just ask me.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

In article , Dave Hansen writes

:-) I know what you mean.

GCC is not usually suitable for 8 and 16 bit embedded systems. IT is a generic compiler system that is not usually a patch onthe commercial ones..

yes.... though some one will now tell us about the 8015 from 197* that was around for 2.3 years :-)

But is it any good?

I once had to work on an embedded system using Mod2 a none of the compilers supported the basic language in the same way. Let alone extensions. It turned out that the most stable compiler was the least standard :-(

A theoretically good language is no use at all if the compiler implementations are no good.

At least with C there will usually be several commercial compilers and a multitude of testing and checking tools.

It's one thing having a compiler but what about the rest. How many ICE support ADA?

Regards Chris

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

Great. I'll keep a lookout.

--
Al Balmer
Balmer Consulting
 Click to see the full signature
Reply to
Alan Balmer

[...]

Avr-gcc actually generates _very_ nice code for the AVR, better than one commercial compiler I use, and comparable with another. Of course, unlike the 8051, the AVR was developed with HLL (esp. C) in mind. For example, it has 32 general-purpose registers.

[...re: 8051...]

You'd have to ask Mr. Granville. Though I think I know what he'd say. ;-)

But as a datapoint, it was able to come within one instruction of my handwritten assembly on a pathological checksum routine I posted back in January of 1999 (seven instructions vs. six). The Keil C compiler I was usingat the time (v5.5 IIRC) was unable to do better than 13, even when using the intrinsics for byte rotation and testing the carry bit.

So from what little I've seen, I'd say it looks quite good.

Fewer implementations implies fewer good implementations, true. At least the odds are reduced. Fewer targetted platforms means your code is less portable as well.

I think I said it earlier in this thread: The only processors I'm aware of that don't have a C or NQC (Not Quite C) compiler are four-bitters. It's ubiquitous.

But C can be, umm, subtle, and static checking tools (particularly Lint) are IMHO _required_. Sadly, they're not often used.

Nit: ICE is hardware. And the various debuggers I've seen shipped with most ICE systems don't support C particularly well either.

And I haven't used an ICE in years.

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

I'd like to hear your thoughts on the noted 100:1 residual error improvement between SPARK code and C code, all DO-178B level A. Do you think the C code examined did not use "a subset, coding standards and static analysis"? If they didn't, who does? Is your claim that, properly used, C can yield equivalent residual error rates as SPARK? If so, why do you think the code examined in the study was a 100 times worse?

Mike

Reply to
Mike Silva

I had a thought about this also. In the Ada case we see a change from R (recommended) to HR (highly recommended) at SIL3 and SIL4. In the C case we see a change from NR (not recommended), past - (no recommendation) and R to HR. To go from Ada to SPARK is one step (i.e. good to best) while to go from C to SIL4-C is three steps (i.e. worst to best). How will that (3 step improvement vs. 1 step improvement) manifest itself in the complexity, cost and lack of errors in the tools, the expressiveness and ease of use of the resulting language subset, etc, etc.

Mike

Reply to
Mike Silva

Would it be fair to say that the product has to be flashy enough to be unbuildable (cheaply) just to make the sale? What I see is people developing a product that has saleable merit, then once the sale is made and they have to make it real they end up retreating to the point of making the same thing as everybody else.

In the end, I don't think the customer values whatever it is they say they want.

Reply to
Simon Hosie

Please, there is a version of GNAT that requires zero run-time support. In fact in the safety critical market it is favored as a base for SPARK, since then there is no need to validate the run-time.

But remember that you really have to think in terms of development host, target, and the ICE or other system used to download and run tests. So the triplet you want may or may not be supported.

There have been several Ada compilers that targetted 8-bit microprocessors. However, I don't think anyone ever validated an 8051 target due to capacity limitations. There is an interesting discussion here, at length, about that topic (in 1995):

formatting link

There is evan a comment there (by me):

"AFAIK the smallest computers that Ada has been targeted to include the 128-kbyte Western Digital P-machines, the Russian PDP-11 clones, and the RRSoft compiler which ran on 512K 8088 based PC-clones.

However, in all these cases the compiler was self-hosted!

So certainly an 8051 target is very reasonable, it just remains to be seen if anyone wants to do it."

I think the situation is still the same, although there are other 8-bit and even 4-bit microcontrollers with Ada targets. So it may just be that programmers who choose Ada choose Motorola microprocessors, and vice-versa. (In point of fact, I've never used an Intel microprocessor in an embedded system, but I have used many Motorola chips, and Z-80s.)

--
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
 Click to see the full signature
Reply to
Robert I. Eachus

I'm jumping into this discussion a bit late, but let me just try an analogy that I have used at my workplace. I think C is to Ada as a motorcycle is to a car. Yes, a motorcycle is likely to be more fun to ride than a car is to drive. Also, an expert rider who rides cautiously might even be able to ride safer than a bad driver can drive. But we all know that, in general, motorcycles are not as safe as cars. Not even close. And if you are trying to develop safety-critical systems with C, that is comparable to using a motorcycle for basic family transportation. Not the wisest thing to do.

But that's just my opinion. If you want the opinions of experts at DoD, MISRA, ARINC, NASA, and CENELEC, check out the one-page summary I put together at

formatting link
. Check out the other links at my Ada page too while you're at it
formatting link

Reply to
Russ

In article , Dave Hansen writes

I like "NQC".... it is a useful TLA as the standards people get in to a tizz when you talk about the C that is on most 8/16 bit embedded compilers.

There is NO EXCUSE for not using a static analyser on C. There are free Lints, Commercial ones i.e. PC-Lint is only a couple 100 USD

I can't see ANY justification for not using some form of Lint with C.

Yes.... of course it is. It is an embedded debugging tool. Somewhat relevant in a discussion on language support in an embedded NG

I have... several.

ICE support C VERY well. As well as (actually better) than simulators.

There is little of no similar support for most other languages. There is some for ADA... Years ago I saw some for Pascal and Modula2 but I don't know any supporting them now.

If you don't use an ICE how do you debug and test?

Regards Chris

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

In article , Russ

that will change in 3 months time with MISRA-C2

61508 has C (with subset etc) as HR the same as Ada.

You will need to modify it.

Whilst looking though some notes I found a table in the IEE Computing & Control Engineering Journal Vol 11.1 The edition was loking at 61508 the paper by R. Bell and PA Bennett.

The table shows failures in safety related systems

44.1% were due to specification faults 20.6 due to changes after commissioning

joint 3rd with 14.7% were: design and implementation operation and maintenance

there was also

5.9% on installation and commissioning.

So it's not down to the language as much as specification and process.....

See the Arianne 5 rocket project. The system failed 29 seconds in due to Sw errors. the problem was not so much Ada but the way it was used and the project managed.

NB the project would have flown if C had been used because C is not strongly typed and the same error would not have been generated.... OK.. I know, if they used C it would never have lifted off in the first place.... :-)

With a good process in place and proper engineering removing the vast majority of errors we start to discover the differences in languages is less important. More important is how good the tools and support tools for a language are.

I know of one very high integrity system that is using C because the quality of the compiler is very high and the support tools are available. They are not available for Ada for the same target. they could not have done the same level of testing and validation.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

Exactly my point. A theoretically good language is useless without the support tools.... And those support tools haveto be of high quality as well.

I am surprised.

That is the problem. A non-validated Ada compiler would be no more value than a good C compiler. Actually a good C compiler eg the Keil C51 that has been extensively used in safety related projects by a large number of people would be better simply because of the empirical field usage compared to a non-validated Ada compiler with a small user base..

That takes some doing!!!

I doubt it. At least not in large enough numbers to justify it especially as 61508 permits C (subset, with coding standard and static checking) to SIL-4

In effect a SPARK-C

Yes there are a LOT!! They are mainly the 186 and 386. There are of course the PC 104 systems but... Strangely due to the sort of projects they 186 and 386 were used in there has been a lot of activity in that field over the last 9 months.... However I doubt this interest will continue (unless somewhere else gets invaded)

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

In article , Mike Silva writes

btw not "worst to best"

I agree to a point. I think this reflects the engineering profession is maturing and the support tools are coming of age.

I think that there are now tools and methods in place that there were not previously. The sheer weight of the commercial pressure has improved quality in the compilers and support tools. It has generated a lot of safety related support for a language that was not originally designed to be a safety critical language.

This does not mean it can't be used for safety related projects just that initially the users were not working in that sort of a field so the mind set was not there. You could write appalling code in Ada but the average practitioner has been taught Ada with a view to safety related systems. The majority of C programmers were not.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

formatting link
\/\/ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Reply to
Chris Hills

That seems obvious. It's possible to write a C program with *no* residual errors. It may be easier to write a SPARK program with no residual errors, but there's no law that says C programs have to have more errors.

Hard to tell, from the given data. Direct access to the study would be needed. I would be surprised if the authors of the study didn't do some analysis of causes.

--
Al Balmer
Balmer Consulting
 Click to see the full signature
Reply to
Alan Balmer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.