« Previously: Ada: What you say is what you get  

Who is using Ada today? While the language has a long-standing history in aerospace and defence, it’s now frequently being adopted outside its original area by a growing number of companies in other embedded domains. Some are in the very enviable situation of having projects to start from scratch.

Adopting Ada or SPARK is very easy then, it’s merely a question of training and there’s nothing fundamentally difficult for a typical embedded developer. Most of those companies, however, have a significant investment in C or C++ code bases - or rely on components developed in those languages. So how do they migrate to Ada? Surely, bearing the costs of rewriting the whole code base offsets any benefits they may get.

Luckily, this is never a requirement. Ada is extremely amenable to language interfacing. As a matter of fact, often C and Ada compilers share most of their code (at least the part responsible for optimizing and generating assembly) making mixing those two an easy task. As an example, the swap function described already could come from a C library:

void swap (int * a, int i1, int i2) { int tmp = a[i1]; a[i1] = a[i2]; a[i2] = tmp; }

 
All we need to do is to tell Ada that this implementation is in C, specifying that it’s imported, of a C convention, and linked to a symbol swap:

procedure Swap (A : in out An_Array; I1 : in Integer; I2 : in Integer) with Pre => I1 in A’Range and I2 in A’Range, Post => A’Old (I1) = A(I2) and A’Old (I2) = A(I1), Import, Convention => C, External_Name => "swap";

 
Hey, isn’t that adding contracts to a C function? Note that although this interfacing code can be manually written, there are also binding generators available that would automatically take care of most of the burden (with the exception of addition of contracts). At the end of the day, only specific software components will be re-written in Ada, most legacy code can be kept. New modules developed in Ada can then be integrated with this legacy code. What you say is what you get. Software engineering is not about writing code, it’s about specifying intent, implementing it and ensuring that what has been implemented corresponds to what has been specified, with as little effort as possible.

This article first appeared in our sister publication, Boards & Solutions + ECE.