Certified C compilers for safety-critical embedded systems

That's kinda the point ... you can't write the driver in Pascal and thus have to give up all of the safety the language was intended to provide.

Modula 2 sucked at bit banging although it did Pascal two better. It allowed "open ended" array parameters - the actual array size and index bounds could be determined at runtime via library functions which enabled array handling functions to be written generically. It also allowed data structures to be accessed as "array of word". However, the size of a "word" was implementation dependent so this feature was of limited value.

Modula 3, designed by DEC and having no relation to the Wirth languages aside from some similarity of syntax, is a modern, strictly typed, object oriented language designed for both application and system level programming. Modula 3 gives the programmer full access, but in a controlled way. Modula 3 divides the world into "safe" and "unsafe" code. "Safe" code does not allow pointers, can perform only a defined "meaningful" subset of possible data conversions and is GC'd by default. "Unsafe" code must be segregated within a library module, but can do pretty much anything it wants: access hardware, use pointers, arbitrarily access memory and data structures, perform arbitrary data conversions, bypass the GC and do custom memory management, etc. There are strict rules governing how data is to be shared between "safe" and "unsafe" code.

Modula 3 is very similar to Ada without subtyping.

Well ... C was intended to be a "portable assembler" for writing operating systems. That design goal required that it provide (nearly) all the power of assembler while abstracting just far enough from the machine to make programs easily retargetable.

No one was forced to use C for general purpose programming. That shift occurred mostly because it was there, it could do what people needed and very few good alternatives were available.

George ============================================== Send real email to GNEUNER2 at COMCAST dot NET

Reply to
George Neuner
Loading thread data ...

No drivers ? Nik Wirths Pascal was indeed close to useless. Intermediate and current implementations allow you to write drivers. Why shouldn't they ?

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
Reply to
Rene Tschaggelar

I realize this is a little OT but I was wondering if there are other embedded controller developers that simply create embedded devices and then hand it over to other companies to do the sales and marketing for them?

Steve

Reply to
Steve Letkeman

The only ranking I have seen on that basis is within IEC61508.

--
********************************************************************
Paul E. Bennett ....................
 Click to see the full signature
Reply to
Paul E. Bennett

Since I'm not developing safety-related systems currently, I can't justify the money for the standard, so I'll just hope that Mr. Silva will have another input.

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

I did something along those lines. For a number of years, I had a limited partnership with a larger company who marketed my stuff in exchange for a share of the profits. One problem was that no one in their orginization understood the technology. Since my entire market consisted of engineers and technicians with sharply tuned bullshit filters, the old "a good salesman can sell anything" credo didn't apply. It turned out that I ended up writing all the meat of the ad copy - to avoid explaining embarrassing statements like "several orders of megahertz better than the competition", went along as technical rep on most important sales calls, and handled all technical questions and a support. After a while I started wondering what I was paying the sales force for.

Bob

Reply to
Bob Stephens

I

Do you think it would make a difference if the product(s) were being marketed to the masses as opposed to the technical crowd?

Reply to
Steve Letkeman

It might, but you're leaving yourself very vulnerable. You build up a business and a clientele, but someone else has all the market data, contact lists, etc.

--
Bill
Posted with XanaNews Version 1.15.8.4
Reply to
William Meyer

Yes, this is called being an invention house. Routine practice in some industries (toys, for instance).

Reply to
Lewin A.R.W. Edwards

It is possible to write interrupt drivers so the math is the same as polled code.

w..

tanya wrote:

Reply to
Walter Banks

Lew> Yes, this is called being an invention house. Routine practice in some

Well it can't have done them any good. When did you last see a new idea in the toy industry?

Reply to
Simon Hosie

I think the Ada and SPARK communities can, which is why I've added comp.lang.ada to this thread. For example, here's reference to a

100:1 residual error reduction between C and SPARK, and a 10:1 reduction between C and Ada, with all code having been previously certified to DO178B level A:

formatting link

Some more interesting reading (note that MISRA acknowledges that there are better languages than C for safety-critical work):

formatting link

This document has a table of language recommendations (search for "Language Recommendations (IEC 1508)" ). C is only recommended for SIL1, while it is not recommended for SIL3 and SIL4:

formatting link

Mike

Reply to
Mike Silva

You missed the point.

We are talking about whether the syntax and semantics of a particular language will allow certain functionality to be expressed. The Pascal language standard defines type rules and expression semantics which prohibit certain operations necessary for low level programming and does not define mechanisms for special use circumventions of those rules. Within the context of our discussion, Pascal can't be used to write a driver.

Dealing with hardware requires the ability to address memory arbitrarily, to manipulate arbitrary bit sequences as meaningful data and to efficiently convert data to bits and vice versa.

Pascal doesn't allow unchecked type casting. Compilers that support it do so as a non portable extension.

The operational equivalent of casting, called "type overlay", requires coercion between pointer types and conversion of non pointer types to pointers. Pascal's type rules don't allow converting non pointer types to pointers or mixed types in pointer expressions (except for "nil"). There is also no standard way to obtain the address of anything. Compilers that support these operations do so as non portable extensions.

Pascal's variant records alone are no help for hardware banging - you still need the support for type overlay so you can "map" the variant type onto the hardware buffer.

Implementations have always provided extensions to allow low level programming - practically since Pascal was invented - because everyone realized it was necessary. But those extensions are *not* Pascal and should not be treated as if they are part of the language.

Some Pascal derivatives do have syntax and sematics that can directly express low level functionality - Ada, Modula 3 and Oberon come to mind - there are probably others I don't know about because Pascal is a popular base model for new language development.

George ============================================== Send real email to GNEUNER2 at COMCAST dot NET

Reply to
George Neuner

Tamagotchi and Furby come to mind. The problem is that the marketing structure through which these new ideas must pass first bites out most of the innovation, then forces the product to be costed-down until it's just another blinkenlight with a 3-second speech chip.

The toy industry is full of idiots, quite frankly. Some of them are idiots merely because they work for a large company and such companies encourage people to rise to the level of their incompetence. Some of them are idiots because they are blinkered. Some of them just enjoy being in a position to reject the creative work of others. Some of them are just in it for the perks and kickbacks provided by suppliers.

A "nameless toy company, division of a nameless enormous consumer conglomerate" with which I'm excessively familiar routinely pays thousands of dollars for exclusive rights to ideas simply so they won't go to another toy company. These ideas are interred in large metal filing cabinets and never see the light of day because they don't fit into a product line.

Reply to
Lewin A.R.W. Edwards

I've thought about that quite a bit and yes, I think a generic marketing approach is better suited to a consumer product than an industrial or technical one. I would recommend some sort of arrangement based on performance, like percentage of sales, rather than a fee, and only give exclusive marketing rights if they will guarantee a minimum number of sales per year. Needless to say, this will weed out all but the true believers in your product line. If you can't find an outfit willing to give you a guarantee, which you probably can't, give them non-exclusive rights to market your products, and incentivise(sp?) them buy discounting their cost, and not undercutting them through your own or other sales channels.

Bob

Reply to
Bob Stephens

An interesting article, though not for the residual error reduction references, which are simply quotes of claims made by Lockheed, with no background. However, the author makes some excellent points, including one I don't see made often enough - that higher level languages tend to increase abstraction but decrease predictability. This is countered to a significant extent by using a well-chosen language subset, like SPARK. In particular, this leads to the possibility of static analyzers which are, in a sense, the logic equivalent of lint's syntax checking.

In reference to "those who maintain that choice of programming language does not matter, and that critical code can be written correctly in any language", he says "The claim may be true in principle but clearly is not commonly achieved in practice." Let me interject that my position is that "critical code can be written correctly in any language" (actually stronger than I would contend), but not that "choice of programming language does not matter." I'd also point out that there is probably more critical code written in assembler and C than in Ada or SPARK :-)

Sorry, but the MISRA recommendations and guidelines are so poorly done that I can't accept them as even relevant. This is not just my opinion, but that of some very well-respected authorities, and has been discussed here on occasion.

This is one in a series of lectures. I would have some fun arguing with the lecturer on some of his points, but he does include the referenced tables from the IEC publication (which I'm too cheap to buy :-)

I think I have to concede that, on the average, code quality can be better with a well-chosen subset of a higher-level language other than C. However, it's still my opinion that "average" programmers, as described in these studies, shouldn't be writing safety-critical code.

Unfortunately, the material presented doesn't give me any idea of the whole development process - I don't know if the code in question was reviewed, linted, or even designed before coding ;-) It may have more to do with other parts of the process than with the language. I won't argue that C and poor process are often found in the same neighborhood.

Since a large part of my work is maintenance of legacy systems, I'll readily agree that the error rate I encounter is horrible. I'll also claim that error rates of programs I've completely reworked are very low. Further, most of the errors I find would have been prevented by good practices, sticking to standard C where possible, and paying attention to compiler warnings. In fairness to my predecessors, some of this code was written before the standard, which excuses about 3% of the problems I find.

Anyway, some very interesting reading. Thank you.

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

That remains true, but hardly anyone today strives to "prove mathematical" correctness. The problem is that Every Instruction could potentially be followed by All interrupt code, unless the interrupts were known to be disabled in a block of code. What the instruction set designers Ought to have invented is a subroutine call that says turn-off-interrupts-and-call and a corresponding return-and-restore interrupts, then code checkers would have shot.

But the results were more deterministic, even if latencies were worse. That is still the tradeoff, isn't it?

Most likely.

No question.

BINGO!

Rick Merrill

Reply to
Rick Merrill

Just to clarify, the error reduction claims I was referring to were those cited from a UK MoD study done by Aerosystems International. I'd like to be able to find that study, or a fuller summary, on line.

Mike

Reply to
Mike Silva

Ah, but do you have a way of preventing that ?

(Not just on systems you build, but on those to which you entrust your own safety.)

One of the big flaws in replacing a software system outright is to ignore the fact that requirement capture has been inadequate.

Reply to
Larry Kilgallen

I'm not quite sure what you mean. In maintenance work, the only reason to modify a program is because it doesn't, in some respect, meet requirements, either the original requirements or new requirements which have evolved. Requirements are rarely static during initial development, let alone a few years down the road :-)

When I say "completely reworked", I don't mean to imply that I rewrite programs from scratch. I make them ANSI compliant and warning free, eliminate unused elements, eliminate globals as far as possible, eliminate unsafe (often erroneous) practices and code, restructure and recode to make the code more maintainable, and where possible replace internal functions with standard C functions or functions from our proven in-house libraries. At that point I can stand to read it, and the real work begins . After this, usually there is considerable refactoring and often some replacement of algorithms. Some testing is done during the process. A code review follows, corrections are made if needed, and more formal unit testing is done before turning the product over to QA.

Typically, during this process, I'll identify a dozen or more bugs in an average thousand-line program. Some of them will be recognized by our support people - "Gee, it's been doing that every couple of months, but we couldn't reproduce it" , or more often "It's always done this, but we have a workaround."

That last, incidentally, is a real problem for us. Our support people are good, and often come up with workarounds to problems they never tell us about. They enjoy being heroes to the customer, and can't be persuaded that they'll never run out of work ;-)

--
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.