|
For novel ideas about building embedded systems (both hardware and firmware), join the 35,000 engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
|
Dan Saks noted (http://www.eetimes.com/discussion/programming-pointers/4372180/Unexpected-trends) recently that embedded.com surveys over the last dozen years indicate that we primarily use C in embedded applications. C++ is a distant second, with everything else being in the noise.
Part of that noise is Ada, a language that dates back thirty years. Once, many developers thought that the language would become dominant, due in part to a DoD mandate that required its use in many of their contracts. Alas, it was not to be.
Today Ada is found most often in safety-critical applications. Its Wikipedia entry contains the clause: "Because of Ada's safety-critical support features, it is now used not only for military applications, but also in commercial projects where a software bug can have severe consequences." "Severe consequence" is much more than airplanes falling out of the sky. Consider the recent Knight debacle. I'm sure the CEO feels a half-billion dollar glitch is a big deal. How about the four million hotel locks - a very simple embedded app - that have a brain-dead security vulnerability? A simple hack with $50 worth of parts can open all of those doors. How many automotive recalls were initiated due to bugs? Then there's that $600 million recall of infusion pumps. And the SCUBA dive computers that gave incorrect - and dangerous - numbers. The list of expensive firmware bugs could fill a book. Even in the most innocuous product that hasn't the faintest tinge of criticality a bug can be expensive or reputation-killing.
There is a small community of Ada users who routinely crank out code an order of magnitude less buggy than common in the C/C++ world. The language has been revised several times. The latest is Ada 2012 which is expected to get an ISO approval this year.
The new version has some fantastic additions. I'm enthusiastic about the new support for Design by Contract, an Eiffel notion created years ago by Betrand Meyer. Meyer believes the way we write functions is broken. He notes that functions don't exist in isolation; they are part of a huge ecosystem of relationships - functions calling other functions with sometimes wild abandon. Those relationships are as important as the code in the functions, and with DbC we write "contracts" that enforce those associations. It's not a new idea. I remember being taught 40 years ago to check goesintos and goesoutas in FORTRAN subroutines. Eiffel has built-in mechanisms to support writing contracts. C doesn't. Some - too few - developers will use the assert macro to detect errors automatically. Ada 2012, though, now includes contracts as part of the language.
So, for example, one can establish a precondition (something which must be true when a routine is entered) or a postcondition (true at exit) that tests, at runtime, a buffer overflow.
A number of studies have shown that the widespread use of contracts, or even of assertions in more primitive languages like C, can detect 80% of the bugs in a program, at roughly a tenth the cost of traditional test and debug.
Ada 2012 comes with a number of other new features. It does not give up the notion of profiles. While a lot of developers shun Ada for its perceived overhead compared to C, subsets like the Ravenscar profile reduce the required runtime footprint considerably.
There's more information available from AdaCore: http://www.adacore.com/adaanswers/about/ada-2012 . And they will have a compiler for the new standard quite soon.
Published August 14, 2012