Re: Ada is great for embedded systems (was Ada is almost useless in embedded systems)

[Ken & Virginia Garlington <redhawk@flash.net>]

Ted Dennison wrote:
> 
> John McCabe wrote:
> 
> > 1) Strong typing is very good if your coders are learners or possibly
> > not very good, and can be useful to guide you in the direction of bugs
> > at the compilation stage but the enforcement of strong typing can lead
> > to code that is difficult to understand because you end up having
> > numerous type casts and unchecked conversions in order to implement
> > something quite simple. C does not enforce strong typing so you can
> > get away with some very strange code, but if you really want to check
> > where you may find problems, you can use 'lint'.
> 
> For Godlike programmers (such as yourself?), perhaps type checking
> is an inconvienence.... [snip]

I always see a discussion of Ada vs. C typing end up here. Let me suggest
an alternative explanation of Ada vs. C typing, which is hinted at in Mr.
McCabe's comment.

If you don't want to use strong typing in Ada, _don't_. You can write Ada
code that has basically the same level of type checking as in C, and it
will run. There's very little in Ada that forces type casts and unchecked
conversions, particularly for simple programs.

Here's the distinction. If I _do_ want to use strong typing in Ada,
and I think it's important for the users of my code to pay attention to that
typing since it's necessary to understanding how my code works, I can do it.
In "C", I can't force users of my code to run lint, purify, and all these
neat C add-ons I see advertised in the magazines for several hundred
dollars a pop. I can put in comments, and cross my fingers, and that's about it.
I know that my code may be used by new hires, or super-programmers coming off
vacation in the Bahamas, so I may want to be precise in how I define my solution.
(See "defensive programming" in the software engineering literature.)

Ada is written in terms of the writer of code defining what should be done
with it, rather than the user. This has its good and bad points, but the Ada
approach is pretty common to manufactured items in general (e.g., the warranty gets
voided if you use the product in a way not defined by the manufacturer). If we want to 
think of software more as a set of manufactured components, and less as an art form, 
then the Ada way seems to be a good way to start. Of course, lots of people like art 
better than manufacturing, so it's not going to please everyone.

> > 2) In the system I am currently developing I have discovered a need
> > use bitwise logical functions on a register which contains 16 bits,
> > all of which are accessed at one time, and all of which have identical

I do this all the time in my Ada 83 embedded systems, so I don't know what the
problem is here. Early Ada 83 implementations were somewhat inefficient with bit
ops, but current products do a reasonable job here.

> > 3) When I'm designing/implementing a system, I like to follow the
> > order of command lists provided in requirement specification when
> > defining enumerated types of these command. I tend to have very little

> 
> So what? As long as they are all there, who cares what order they are
> listed in? I don't see how this cripples Ada to the point where it is
> useless. C doesn't even HAVE enumerated types! You'd have do use
> a series of constants, which you can do in Ada as well!!

I think the issue is: If in the spec, a discrete is listed as Open/Closed, then
it would be nice for the type to read (Open, Closed). However, if Open=1 and
Closed=0, then you have to reverse the order in the type. I've never noticed
this in our embedded systems, since our engineers list these in ascending order.

It is a good point that Ada enumerated values are really useful in embedded systems,
particularly those with a lot of inverted discretes (e.g. On=0, Off=1). It is
much less error-prone than using constants, where the old cut-and-paste error

  On: constant := 0;
  Off: constant := 0;

always seemed to be hanging around.

> > 4) Pascal provides variant records, C provides unions and Ada provides
> > variant records. What differences are there between these? Obviously I
> > am aware that none of these languages guarantee that the variants are
> > front of the record type. How can you map this onto e.g. a 1553 bus
> > command buffer where the command structure is NOT defined to fit into
> > the Ada variant record type structure? This has been implemented in my

Actually, we've not had any problems using Ada with our 1553 interfaces. It
may be that our mappings are just a little less perverse...

> > 5) Finally chapter 13. What is the point of having a program to come
> > up with a portable, general purpose, 'standard for use in DoD
> ...
> > reasoning of this and I think it is stupid. At work we have 3 Ada
> > compilers for MIL-STD-1750A targets and we have been surprised at the
> > amount of work that is involved in getting a single piece of code to
> > compile under all three. Previously I used Motorola's implementation
> > of GCC for a DSP56001 target, and the HP UNIX ANSI standard compiler
> > on a single piece of code, without modification, and they both
> > compiled the code perfectly. This proves to me that C is a far more
> > portable language than Ada.

Have you tried to port C code between three different 1750 compilers? For some
reason (probably the small user base), comparisons of 1750 target compiler
capabilities vs. host compilers (e.g. HP) always come off bad. This
is true for Ada, and I suspect it's true for C as well. (Did you have any trouble
getting the HP to fix in the same space as the 1750? :)

However, we have ported large chunks of code between DEC Ada, Telesoft Ada/1750,
and Tartan Ada/1750 with no trouble. So, it may be a consequence of the way you
had to write your Ada code, or you just picked some bad compilers, or you need the
extra power of Ada 95 to make your code portable. I don't know.