Re: Ada and Automotive Industry

[Ken Garlington <garlingtonke@lmtas.lmco.com>]

John Dammeyer wrote:
> 
> My justification for such a sweeping comment is that if the programmer
> has to change or limit his/her language usage in order to comply with
> the hardware restraints of the processor then the chosen language is
> not longer the language as defined and the much touted power of a
> particular language becomes a moot point.

Having used Ada for the MIL-STD-1750A, I've certainly had to make compromises
in the use of the language to comply with the hardware constraints of that
processor, and I've still been able to see significant benefits in using Ada.

As Dr. Dewar mentioned in a previous post, many of the most beneficial
aspects of Ada, such as packages, are _static_ concepts. They don't depend
upon a particular set of hardware resources. More importantly, these features
support the very heart of good software engineering, and they are more
difficult to emulate in either assembly or "C".

If I don't have tasking (to pick an Ada feature at random), I haven't necessarily
made the language "moot". It depends upon (a) if my application design needed
a lot of parallelism and (b) what alternatives, such as using procedures as
interrupt handlers, remain to express that parallelism. For tiny processors,
a design which requires 256 tasks may very well be unsupportable in _any_ language,
so that _design_ is moot for the architecture, not the language!

> Part of the power of the C language, especially for Operating Systems
> and embedded applications, stems from the rich use of pointers and
> pointer arithmetic.  PIC architecture and this particular
> implimentation severely limits pointer usage.  A particular danger
> area in the PIC family is when a constant string overlaps a ROM page
> boundry or a multi-byte variable overlaps a RAM page boundry

Ada, on the other hand, is not as tied to a pointer model. Therefore,
Ada _might_ be a more appropriate language here.

Note that MIL-STD-1750s have a similar problem of data structures overlapping 
certain page boundaries. It's fairly easy to solve, if your Ada toolset provides
the proper support.

> Another powerful concept is passing parameters by value or by
> reference.   This allows information hiding and generalized
> subroutines.  The MPX implimentation limits parameters two two bytes
> total; one far pointer(16 bits), long int(16 bite)  or two
> integers/chars*8 bits each).  Those two bytes will then be stored in
> global memory accessable only from within the function.  ie; each
> parameter byte is lost RAM.  Local variables in functions can be
> explicitly overlapped over other RAM memory but this, implies a lot of
> work on either the compiler writers end or the applications
> programmer.  The potential for an undetected error is frightening.

Actually, this is a case where I think Ada packages might be an extremely
powerful tool. An obvious alternative to passing parameters is declaring
global variables, and this is what often happens with limited architectures.
However, with Ada, I can still practice information hiding by declaring these
objects in package bodies, or in private child packages. So, although
I lose some generality, I've still got an advantage over older languages.
More importantly, this is still _standard_ Ada. If I port this code to a
more powerful architecture, it should still work.

> Perhaps some programming shops insist that their applications
> programmers only use a minimal subset of the language.  If so then why
> ADA or ALGOL-68 or C++.

Again, because it's not an "all or nothing" situation. For example,
I've heard a lot of people say "don't use Ada generics, they're too
slow." We've used Ada generics for years without problem. Just because
your toolbox is full of tools, you don't have to use every tool on
every project.

-- 
LMTAS - "Our Brand Means Quality"
For more info, see http://www.lmtas.com or http://www.lmco.com