Re: Ada in Embedded Systems Programming.

[jmills@ccrf-news.gatech.edu (John M. Mills)]

In article <38qt85$as2@theopolis.orl.mmc.com>,
Ted Dennison <dennison@romulus23.DAB.GE.COM> wrote:
>.. I think there is a lot more embedded
>Ada programming than you may be aware of. 

I'm sure there are many I'm unaware of, but it is interesting how many folks
suggest that we are pioneers for doing it.  Actually we don't use any radical
tools, and many better ones [than what we use] are now available.

>So what is the problem with Ada for embedded applications?

Nothing, if you can afford enough target processor.  My point was that more
applications would _benefit_ from Ada if some reduced-function compilers
could target common microcontrollers and fit executables into a few tens of
KBytes of RAM and ROM.  You could benefit from the compile-time qualities,
if you forwent some run-time features and libraries.

>Well, a quick search through the list of validated compilers confirms your 
>suspicions; I couldn't find any validated 8051 cross compiler. The 8051 is WAY

This doesn't explain the ads I see every couple of months for newer and faster
8-bit microcontrollers, including 8051-variants and compatibles, nor the number
of ads for cross-compilers (C, of course), emulators, and related tools.  The
fire alarm/security system just installed  in our building uses two 8085 CPUs.
Appalling from a technical standpoint, but obviously current technology.  (The
last 80xx code I wrote was for 8085s, ten years ago.  It's probably still
running, however.)

I would settle for a 16-bit target with small ROM and RAM partitions.  I expect
the processor chip isn't such a driver as the support silicon.  Recently we
were asked to identify Ada tools to transition a 16-bit single-card missile
telemetry controller from assembly language.  After hearing the price, the
client was overjoyed to hear about the target memory requirement, since that
was so much larger than their hardware, it allowed them to instantly dismiss
the expen$ive Ada tools.  (Our recommendations matched frequently-given
advice here -- don't bother to flame me for not reading the validated compilers
list.  We also talked to support engineers identified by the vendors.)

>Nonetheless, I'm sure someone will port GNAT to it if there is
>any kind of demand.

I've always thought of FSF and the GNU project as the one successful example
of Supply Side Economics!

>Cross compiler vendors commonly use a reduced version of the the Ada runtime
>(eg: no tasking or dynamic memory allocation/deallocation). Is this the kind
>of thing you are thinking of?

Yes -- There are probably ways to address this and come out with smaller
executables.

This problem isn't restricted to Ada -- I managed one project with Intel
FORTRAN 77 (extended) on a '286 processor.  Our in-house-code size estimates
were within about 20%, but Intel's libraries linked about five times what they
had estimated for us.  Fortunately it was no bell-ringer in that application.

Regards --jmm--

-- 
John M. Mills, SRE -- john.m.mills@gtri.gatech.edu -- (404)528-3258 (voice)
   Georgia Tech/ GTRI/ SDL, 7220 Richardson Rd., Smyrna, GA 30080
     Inez Has Tiny Fuzzy Poodles - II'67