Re: Ada and embedded applications

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

I have not followed GNORT with any serious use in mind. I can't speak for
where that may or may not be.

As for exceptions and DOS: That isn't specifically an Ada thing. I've used
Ada compilers that targeted bare hardware and used no RTOS other than what
they brought to the table. Typically, we turned off most of the run time
error checking because of speed issues - but then we were unusually hard on
processor budgets. You *always* have to remember that what GNAT does is
*not* the same as saying what Ada does - whatever GNAT does for exception
generating & handling is not necessarily going to be what all Ada compilers
(or even GNAT) will do on all different platforms. As with any other
embedded project, you must spend time up front evaluating compilers and
vendors against your requirements. Failure to do so can get real expensive.

When you talk about budgets, what precisely do you mean? Processor/Memory
budgets or actual project $$$ budgets? There is no particular reason you
can't do real-time, embedded work in Ada under the same processor/memory
budgets as you would have for C. (Availability of compilers may be an issue
for a particular processor...) You have to know your compiler and know what
parts of it are going to cost you speed/space & try to understand how to
work with it to optimize things best. That is the same issue with any
language or compiler. For example - tasks are going to force you to have
some kind of runtime library overhead plus space & speed. Usually, you can
do something about it by simply not using tasks and having the linker
eliminate dead code. Sometimes, you may need to tailor the RTK - but that is
all compiler dependent. In the case of C you can't decide to *start* using
tasks because they don't exist. You'll have to grow your own if your app
needs some kind of multi-threading & I'll bet it gets more cumbersome &
inefficient than had you just used Ada. FWIW, I've built realtime systems on
incredibly small/slow processors using Ada and had to fight for every CPU
cycle. I can't give you scientific evidence because we never tried to do it
both in Ada and C, but from my experience, I don't think we'd have had any
speed advantage using a C compiler. We had a very good Ada compiler and
evaluating the code that came out of it, it was hard to imagine getting code
that was better for the structures we were using. (Granted, we were using
very few features - not lots of tasking (some) or complex data
representations or OOP features or anything like that. Math calculations, if
checks, data representations using records and not much else.)

If you are talking $$$ to do a project, then it gets a little fuzzier. As
well you know, GNAT is available at no cost, but you're on your own for
support at that price. So is GCC. You can always buy support - sometimes at
high prices - for either compiler. RR Software has an inexpensive Ada
compiler, but I don't think they target the embedded market - unless your
"embedded system" is really a PC running windows - which is a little like
cheating. Aonix had a nice embedded Ada compiler for not too many $$$ for a
number of targets. Price compared to C? Depends on what you get. There are C
compilers given away with development kits for specific board level
products. Aonix I think started at around $700 a bunch of years ago and
depending on what you wanted, the $$$ went up. But on a product of any
significant size, the cost of the compiler was pretty much below the noise
level. Green Hills has a compiler with multiple front-ends that will target
a number of processors. Essentially, you get Ada or C (or a few other
languages) as a choice for the front end & buy basically the same back end &
development tools. The cost has got to be roughly the same. I just don't see
the costs as being hugely different or even a major concern since you have
options in either case.

If you've got some teeny-tiny processor you'll probably find that there is
no Ada as a choice for it. That's one reason C is so popular with the
embedded world. Most SBCs and smaller processors have a C compiler
available. Could you get Ada on them? Maybe. Maybe not. Ada *will* have a
problem fitting on a lot of smaller processors because if you want it
validated, you've got to find a way to get lots of features out of a chip
that may not offer much support for them. (Floating point? Context switching
for tasks? Lots of things get to be a problem on small chips.) C, lacking
much in the way of features and not exactly having validation as one of its
strong points, has an easier time fitting on small chips. No floating point
support? No problem. Integer-C only. No tasking support? No problem - there
are no tasks. That's where Ada is going to have a hard time. But of course,
hardware just keeps getting faster, bigger & cheaper, so maybe one day the
16-bit micro-controllers won't be an issue for anybody. (Want to build an
embedded controller for a toaster? No sweat! Here's your PowerPC chip with
on-board 128 meg of memory for $0.39 in production quantities of ten.)

As for moving compilers to new targets - it depends a lot on the compiler.
GCC (and by insinuation, GNAT) have a lot of unsupported back-ends out there
that target a lot of wierd machines. I don't imagine they'd get so many if
customizing the compiler was a horrendously hard effort - or was only easy
if you were dealing with C on the front end. I don't think it would take a
whole lot longer to build the back end for a new machine with Ada as the
front end than it would for C. There would be some runtime library porting
that may get a bit bigger with Ada, but the bulk of the work on *any*
compiler is not the parsing of the source language, but the generation of
code & optimization. If the compiler is set up to be easily retargeted, I
don't think the source language is going to matter much. OTOH, if the
compiler is itself highly customized to Ada language features, I could see
how it might be a bigger job to retarget. The level of effort is going to be
really dependent on the architecture of the compiler, not the language.

--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/


"Chris Campbell" <chris.danx@ntlworld.com> wrote in message
news:XPSS6.23515$HL5.2779772@news6-win.server.ntlworld.com...
>
> > Ada in general allows compilers to be creative about how they handle the
> > implementation of features to be as small and/or efficient as possible.
For
> > example, GNAT has a version that restricts some features of the language
in
> > order to be able to go to a "No Runtime" result. (Its called GNORT, in
case
> > you want to do some searching for info on it.) You lose some features,
but
> > can make code that doesn't depend on anything but what you provide. GNAT
> > itself is available for the cost of a download if you don't need
support.
> > (Don't know for sure about GNORT.) So I don't think it ought to be a
> > budgetary issue. Many embedded projects are using GCC as their
compiler -
> > GNAT isn't any different in how it can be used.
>
> GNORT has been discontinued by ACT.  Maybe they integrated it into GNAT.
>
>
> > As for exceptions - the space/speed is going to vary depending on the
> > compiler. Again, there isn't anything in there that requires megabytes
of
> > memory or huge processing overhead, but all compilers are different. I
think
> > you'd find that whatever overhead is there that it isn't excessive - or
even
> > the biggest ticket item on the list of features.
>
> I suppose if i could keep exceptions in it'd be good since i'd know where
the OS
> crashed.  Still it I can't since GNAT must use some DOS or windows calls
to
> display the point where the exception occured.  This is really annoying me
now.
> I didn't even consider exceptions when i settled on Ada for this project
but now
> i can see they could be benefitial -- In Ada exceptions are always there
letting
> you know when something goes barmy.
>
>
> > With Ada, if you really need to, you can turn off the standard
exceptions
> > and if you don't create any of your own, you should impose no additional
> > overhead on your program. C gives you no choice in the matter. You have
to
> > be *very careful* when listening to C programmers talk about Ada because
> > usually they base their criticisms on a variety of rumors, FUD,
> > misinformation, etc., or a BAD experience with one particular compiler
> > developed 15 years ago. (Like getting a BAD meal in a restaurant - maybe
it
> > was just one bad day for an otherwise good restaurant, but it left a bad
> > taste in your mouth and you never go back.)
>
> That's why i was curious and decided to find out why.  I also wanted to
put the
> guy right if need be.  I still can't do that because I still don't know if
Ada
> is less favoured when budgets are tight.  It doesn't seem to me, from
what's
> been said in this thread so far that exceptions take up that much extra
memory
> and it shouldn't really matter(but then i've never programmed an embedded
device
> before).  If i were a program developer for a life support machine i'd
rather
> use Ada than C.  If the worst happened and someone died unneccessarily due
to a
> bug, you'd stand a better chance of finding it with Ada.
>
> The other reason he gave i tend to agree with:  it can be slow to develop
> compilers for new processors, but in some ways it can take a while to get
a C
> compiler for the new processor, Ada however is much more complex than C
and will
> take more time starting from scratch.
>
> Out of interest GNAT is based upon GCC i think and GCC compiles things to
an
> intermediate form -- a RTL -- (is this right?) so all you'd really need to
do is
> port specific parts of GNAT to the OS if any on the new processor and have
a GCC
> backend that compiles to that processor.  It seems like it really wouldn't
take
> that long after you've got this.  Is my understanding of this all barmy?
>
>
>
>
> Chris Campbell
>
>
>