Ada and embedded applications

Ada and embedded applications

[Chris Campbell]

Hi,

On another group a discussion about various languages errupted and it took a
while to get anything positive out of it(it's started as the old "my language is
best" debate).  Now the discussion seems to be focussed on distance from
hardware, like C being relatively close to hardware.  This is largely irrelevant
background.

One poster claimed that Ada was not used in some embedded devices because of
memory overheads for exception handling.  Claiming it was used in embedded
devices in industries that had budgets that supported it (e.g. the aerospace
industry).


Is this correct or is it rubbish?  Also does exception handling in Ada really
have a large overhead?  (This is probably an implementation issue but is their
anything in the language that makes exception handling bulky?).

I'm curious because one of the projects i'm working on involves writing an OS.
It's supposed to be as small as possible and i wouldn't want too many overheads.
(Also are exceptions dependant on platform? i.e. the mechanisms for flagging an
exception dependant on the OS?  If so the GNAT pragma No_Runtime would eliminate
this, but i'd have no exceptions to tell me if my code's buggered).




Chris Campbell.

Re: Ada and embedded applications

[Marin David Condic]

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.

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.

Think about it this way: Real-world embedded applications need to do a
variety of failure detection & accommodation things. You have to do checks
for math overflows, out of bounds references, out of memory conditions, etc.
etc. Ada provides you with exceptions which require some non-zero overhead
to deal with. C provides you with *nothing* and hence has no overhead. The
problem is that because you still need to check for error conditions, you're
going to have to do *something* on your own - thus creating more overhead.
It makes C look great for a while ("Look! No overhead!") until you realize
you've got all this extra code hanging around doing error processing of some
form. Usually, compiler generated stuff is going to end up more efficient in
the long run, especially for more mature compilers. Ada is really good for
applications that have a high reliability requirement specifically because
of all the checking it does (compile and run time) for error conditions. If
you think Ada is expensive, get a price quote on failure! :-)

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.)

MDC
--
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:LTQS6.29382$%_1.5022327@news2-win.server.ntlworld.com...
> Hi,
>
> On another group a discussion about various languages errupted and it took
a
> while to get anything positive out of it(it's started as the old "my
language is
> best" debate).  Now the discussion seems to be focussed on distance from
> hardware, like C being relatively close to hardware.  This is largely
irrelevant
> background.
>
> One poster claimed that Ada was not used in some embedded devices because
of
> memory overheads for exception handling.  Claiming it was used in embedded
> devices in industries that had budgets that supported it (e.g. the
aerospace
> industry).
>
>
> Is this correct or is it rubbish?  Also does exception handling in Ada
really
> have a large overhead?  (This is probably an implementation issue but is
their
> anything in the language that makes exception handling bulky?).
>
> I'm curious because one of the projects i'm working on involves writing an
OS.
> It's supposed to be as small as possible and i wouldn't want too many
overheads.
> (Also are exceptions dependant on platform? i.e. the mechanisms for
flagging an
> exception dependant on the OS?  If so the GNAT pragma No_Runtime would
eliminate
> this, but i'd have no exceptions to tell me if my code's buggered).
>
>
>
>
> Chris Campbell.
>
>

Re: Ada and embedded applications

[Chris Campbell]

> 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

Re: Ada and embedded applications

[Matthew Woodcraft]

"Chris Campbell" <chris.danx@ntlworld.com> writes:

> Out of interest GNAT is based upon GCC i think and GCC compiles things
> to an intermediate form -- a RTL -- (is this right?)

Not quite - RTL is processor-specific. There is a processor-independent
intermediate form, but it comes earlier in the compilation process than
RTL.

> 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?

That's more-or-less right. Creating a GCC back end for a new processor
is a decent-sized job, but in most cases one will already exist, and the
'only' effort would be making it work with GNAT. That's very little
effort compared with writing an Ada compiler from scratch, for sure, but
nonetheless I guess it's tricky to do correctly.

-M-

Re: Ada and embedded applications

[Ted Dennison]

In article <XPSS6.23515$HL5.2779772@news6-win.server.ntlworld.com>, Chris
Campbell says...
>
>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.

Given that goal, I'd be tempted to try make a special compiler version just for
the kernel that does a BCOD (blue-screen-of-death) message.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Ada and embedded applications

[Chris Campbell]

> >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.
>
> Given that goal, I'd be tempted to try make a special compiler version just
for
> the kernel that does a BCOD (blue-screen-of-death) message.

I like that idea!  I want the OS to be as good as possible in all respects, this
means that if there is an exception i wan't to know it's details so i can track
down the bug.


How would i start with that(making the special)?  Getting the sources is first,
what then?


Chris Campbell

p.s. i wan't be sure were talking about the same thing.  Are you suggesting i
should make a special version of GNAT that i can code the kernel in?  (this is
what i've assumed above). Or are you suggesting i port GNAT to the OS once the
kernel is coded?

Re: Ada and embedded applications

[Chris Campbell]

> I like that idea!  I want the OS to be as good as possible in all respects,
this
> means that if there is an exception i wan't to know it's details so i can
track
> down the bug.
>
>
> How would i start with that(making the special)?  Getting the sources is
first,
> what then?
>
> Chris Campbell
>
> p.s. i wan't be sure were talking about the same thing.  Are you suggesting i
> should make a special version of GNAT that i can code the kernel in?  (this is
> what i've assumed above). Or are you suggesting i port GNAT to the OS once the
> kernel is coded?


Sorry I was half asleep when i wrote that.

The idea of creating a version just for the kernel is a good idea Ted.  I'm
gonna get the source for GNAT (i think it's available) and make a start.  My
first problem will be to get rid of the system dependant code, and maybe replace
it if possible.  One thing concerns me, consider tasks for example.  I can't
implement tasks in the compiler due to the nature of the work i'll be doing.
Tasks are highly dependant on the native OS so i'll reprogram bits, but to do
what?  Is there something that a compiler should do when a language feature
isn't supported?

Also which distribution of GNAT should i get for this?  I think the DOS
distribution since it's probably very close to what i need (tasking doesn't
really become an issue since it doesn't work yet, or that's what i remember
seeing somewhere).  I think i'll need to get DJGPP to compile the whole thing,
hmm ... nope got that already.

Chris Campbell

Re: Ada and embedded applications

[Ted Dennison]

In article <cf0T6.122$YB3.72776@news2-win.server.ntlworld.com>, Chris Campbell
says...
>
>it if possible.  One thing concerns me, consider tasks for example.  I can't
>implement tasks in the compiler due to the nature of the work i'll be doing.
>Tasks are highly dependant on the native OS so i'll reprogram bits, but to do
>what?  Is there something that a compiler should do when a language feature
>isn't supported?

For building a microkernel, I'd imagine you'd want to create a "no tasking"
program. I believe Gnat has custom pragmas to enforce that.

>Also which distribution of GNAT should i get for this?  I think the DOS

There appears to be only one source distribution for Gnat, so the answer to this
is trivial. The tougher question is what target you should configure it for when
you build the compiler. I'd guess that the best way to start would probably be a
Windows to bare x86 cross-compiler. I haven't looked at the source distribution
myself, so I don't know how much work that would be.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Ada and embedded applications

[Marin David Condic]

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
>
>
>

Re: Ada and embedded applications

[tmoran]

>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
  I used to regularly compile and run Ada 83 programs in 16 bit DOS on
a 286, often generating a small memory model (64K) .com file.  But I grant
that's gigantic compared to 512 bytes of RAM.

Re: Ada and embedded applications

[Marin David Condic]

I wouldn't say that it is *impossible* to get an Ada program into 512 bytes
of memory, but you'd have to have a compiler that made it possible to build
code with no runtime (like GNORT) or you might find yourself dragging along
way too much other stuff. Technically speaking, I don't think this is a
*language* problem - more one of a *linkage* problem. There may be some
language issues such as this: I write a single procedure to run in my 512
bytes of memory. Will Ada demand that there be some kind of
elaboration/initialization/finalization that takes place such that I've got
to drag along more stuff than I need? Could a compiler be built (and would
it be *legal* Ada or a subset?) that was smart enough to detect that my
single procedure program required nothing but jumping to the starting
address and executing from there? I'd suspect thjat the answer is "Yes, but
it may require bending language rules and will certainly require you don't
use specific features."

Naturally, you couldn't use the whole of the Ada language in a setting like
that, which raises issues of validation. It may be possible to target Ada
for that sort of microcontroller, but it doesn't seem to be high on
anybody's priority list. Possibly it is viewed as a) too difficult to
accomplish in a reasonable span of time and b) too little interest on the
part of the folks who program these things to make it worth investing the
energy in it.

MDC
--
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/


<tmoran@acm.org> wrote in message
news:akXS6.63509$%i7.48165181@news1.rdc1.sfba.home.com...
> >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
>   I used to regularly compile and run Ada 83 programs in 16 bit DOS on
> a 286, often generating a small memory model (64K) .com file.  But I grant
> that's gigantic compared to 512 bytes of RAM.

Re: Ada and embedded applications

[Jeffrey Carter]

Marin David Condic wrote:
> 
> I wouldn't say that it is *impossible* to get an Ada program into 512 bytes
> of memory, but you'd have to have a compiler that made it possible to build
> code with no runtime (like GNORT) or you might find yourself dragging along
> way too much other stuff. Technically speaking, I don't think this is a
> *language* problem - more one of a *linkage* problem. There may be some
> language issues such as this: I write a single procedure to run in my 512
> bytes of memory. Will Ada demand that there be some kind of
> elaboration/initialization/finalization that takes place such that I've got
> to drag along more stuff than I need? Could a compiler be built (and would
> it be *legal* Ada or a subset?) that was smart enough to detect that my
> single procedure program required nothing but jumping to the starting
> address and executing from there? I'd suspect thjat the answer is "Yes, but
> it may require bending language rules and will certainly require you don't
> use specific features."

Pragma Preelaborate exists to allow the elimination of elaboration,
including initialization. Obviously you can't use controlled types in a
pre-elaborable unit, so finalization disappears, too. I would think that
if you can get the compiler to accept your procedure with pragma
Preelaborate that it would do what you want.

-- 
Jeff Carter
"I blow my nose on you."
Monty Python & the Holy Grail

Re: Ada and embedded applications

[Randy Brukardt]

tmoran@acm.org wrote in message ...
>>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
>  I used to regularly compile and run Ada 83 programs in 16 bit DOS on
>a 286, often generating a small memory model (64K) .com file.  But I
grant
>that's gigantic compared to 512 bytes of RAM.

Re: Ada and embedded applications

[Randy Brukardt]

tmoran@acm.org wrote in message ...
>>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
>  I used to regularly compile and run Ada 83 programs in 16 bit DOS on
>a 286, often generating a small memory model (64K) .com file.  But I
grant
>that's gigantic compared to 512 bytes of RAM.

As I recall, that version could make useful programs that fit in 16K ROM
and 2K RAM. The only reason to prefer C is ignorance...

                Randy.

Re: Ada and embedded applications

[Marin David Condic]

....or availability. C has the advantage over Ada in that you can usually
get some version of a C compiler for a lot of small microcontrollers. Ada is
around for some 16 bit processors (not necessarily the most popular, either)
and most of the more generally used 32 bit processors (M680x0, Mips,
PowerPC, 80x86, etc.)

I'd say that anyone who prefers C over Ada in a host/target environment
where a descent implementation of Ada is available is doing so out of
ignorance (Or anti-Ada bigotry). For lots of popular processors you have
good Ada implementations & no reason not to gain its advantages over C. For
quite a few smaller processors your choices quickly become C or Assembly
language and I'd rather use C than Assembly.

This may be blasphemy, but I'd be in favor of an Ada subset for small
microcontrollers wherein any features too hard to implement or too costly
were dropped. I'd want the Ada features that had compile-time implications
(rep clauses, static checks, etc.) but would willingly abandon run-time
features (floating point, big integers, whatever) in order to have Ada as a
choice over C. That's one area where "The Mandate" ended up hurting Ada. If
there had been a 100% upward-compatible subset of Ada available for small
embedded machines, it might not have received so much resistance and might
have seen more "evolving" implementations. In the early days, Ada just bit
off more than she could chew & we're still paying that price.

MDC
--
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/


"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:zt9T6.39$yq2.1735@client...
>
> As I recall, that version could make useful programs that fit in 16K ROM
> and 2K RAM. The only reason to prefer C is ignorance...
>

Re: Ada and embedded applications

[Martin Dowie]

It hasn't been discontinued, it's been renamed to
"GNAT Pro High Integrity Edition" - really trips off the tongue! :-)

And is the Ravenscar Profile edition will be called GRAVEN?

> GNORT has been discontinued by ACT.  Maybe they integrated it into GNAT.

Re: Ada and embedded applications

[Marin David Condic]

I really wish that the whole GNU thing had gone off in another naming
direction. We've been stuck for years - and will continue to be stuck for
years to come - with a whole slew of awkward names stemming from the "GNU"
acronym.

One day, comes The Revolution, and I get to run the whole world, we'll name
all software/systems after ex-girlfriends or favorite pets, or dead
presidents or *anything* that doesn't have to be an awkward acronym. ("Let
me demonstrate my new Ada compiler. I call it 'Laura-Muffy-Rosevelt'" :-)

But that's just my pet peeve....

MDC
--
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/


"Martin Dowie" <martin.dowie@nospam.baesystems.com> wrote in message
news:3b1c8b72$1@pull.gecm.com...
> It hasn't been discontinued, it's been renamed to
> "GNAT Pro High Integrity Edition" - really trips off the tongue! :-)
>
> And is the Ravenscar Profile edition will be called GRAVEN?
>
> > GNORT has been discontinued by ACT.  Maybe they integrated it into GNAT.
>
>
>

Re: Ada and embedded applications

[Martin Dowie]

"Marin David Condic" <marin.condic.auntie.spam@pacemicro.com> wrote in
message news:9fio0s$2n5$1@nh.pace.co.uk...
> One day, comes The Revolution, and I get to run the whole world, we'll
name
> all software/systems after ex-girlfriends or favorite pets, or dead
> presidents or *anything* that doesn't have to be an awkward acronym. ("Let
> me demonstrate my new Ada compiler. I call it 'Laura-Muffy-Rosevelt'" :-)

I won't ask which is which... :-)

Re: Ada and embedded applications

[Rod Chapman]

> GNORT has been discontinued by ACT.  Maybe they integrated it into GNAT.

GNORT has simply changed name - it is now called GNAT Pro High-Integrity
Edition, and is fully supported by ACT.  I'm sure there must be details
on www.gnat.com somewhere...
 - Rod

Re: Ada and embedded applications

[Larry Kilgallen]

In article <LTQS6.29382$%_1.5022327@news2-win.server.ntlworld.com>, "Chris Campbell" <chris.danx@ntlworld.com> writes:
> Hi,
> 
> On another group a discussion about various languages errupted and it took a
> while to get anything positive out of it(it's started as the old "my language is
> best" debate).  Now the discussion seems to be focussed on distance from
> hardware, like C being relatively close to hardware.  This is largely irrelevant
> background.
> 
> One poster claimed that Ada was not used in some embedded devices because of
> memory overheads for exception handling.  Claiming it was used in embedded
> devices in industries that had budgets that supported it (e.g. the aerospace
> industry).

Efficiency of exception handling obviously varies among implementations,
but I worry about any design that is going to encounter so many exceptions
that their performance becomes relevant.

Re: Ada and embedded applications

[Ehud Lamm]

Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote in message
> Efficiency of exception handling obviously varies among implementations,
> but I worry about any design that is going to encounter so many exceptions
> that their performance becomes relevant.

Perhaps one should note that there can be implementations in which exception
handling support causes overhead even for programs and routines that don't
raise or handle exceptions.


--
Ehud Lamm   mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <==  Me!

Re: Ada and embedded applications

[Ted Dennison]

In article <9fgq5t$hok$1@news.huji.ac.il>, Ehud Lamm says...
>
>Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote in message
>> Efficiency of exception handling obviously varies among implementations,
>> but I worry about any design that is going to encounter so many exceptions
>> that their performance becomes relevant.
>
>Perhaps one should note that there can be implementations in which exception
>handling support causes overhead even for programs and routines that don't
>raise or handle exceptions.

If your definition of "overhead" includes the executable's memory footprint, I
think all programs would qualify.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com

Re: Ada and embedded applications

[Marc A. Criley]

Ehud Lamm wrote:
> 
> Larry Kilgallen <Kilgallen@eisner.decus.org.nospam> wrote in message
> > Efficiency of exception handling obviously varies among implementations,
> > but I worry about any design that is going to encounter so many exceptions
> > that their performance becomes relevant.
> 
> Perhaps one should note that there can be implementations in which exception
> handling support causes overhead even for programs and routines that don't
> raise or handle exceptions.
> 

I know ACT was touting "zero-cost exception" technology for some GNAT
platforms a year or so ago, which was intended to alleviate exactly this
concern.  (Without Dewar being here, nor being a supported customer, I
don't get much ACT press info any more :-(

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
www.quadruscorp.com

Re: Ada and embedded applications

[Pascal Obry]

"Marc A. Criley" <mcqada@earthlink.net> writes:
> I know ACT was touting "zero-cost exception" technology for some GNAT
> platforms a year or so ago, which was intended to alleviate exactly this
> concern.  (Without Dewar being here, nor being a supported customer, I
> don't get much ACT press info any more :-(

Look at the -gnatZ option in gnatmake and in the documentation. I don't have
the list of supported platforms for ZCE.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|         http://perso.wanadoo.fr/pascal.obry
--|
--| "The best way to travel is by means of imagination"

Re: Ada and embedded applications

[Robert A Duff]

"Chris Campbell" <chris.danx@ntlworld.com> writes:

> One poster claimed that Ada was not used in some embedded devices because of
> memory overheads for exception handling.

Sounds like nonsense, but it's not completely clear what that poster
meant.  An exception handler typically costs a small number of words of
space for certain tables.  Even if those tables were huge (not likely),
you don't have to use exception handlers if you don't like.  It's silly
to use C because when using Ada you might be tempted to use an
inefficient feature that C doesn't have at all.

I don't think Ada exception handlers have any *distributed* overhead --
that is, you don't pay anything substantial for the mere existence of
exception handling in the language, if you don't use it.  (Unless you're
talking about combining exception handling and finalization -- but C
doesn't have finalization, so that can't be the issue.)

Perhaps that poster was talking about the space overhead of run-time
checking (array bounds and the like).  That overhead exists, but it's
not all that high, and anyway, pragma Suppress will turn it off.

>...  Claiming it was used in embedded
> devices in industries that had budgets that supported it (e.g. the aerospace
> industry).

That sounds like nonsense, too.  I wouldn't believe it unless some
(current) prices were quoted for comparison.

- Bob

Re: Ada and embedded applications

[Chris Campbell]

"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wccsnhg6j6v.fsf@world.std.com...
> "Chris Campbell" <chris.danx@ntlworld.com> writes:
>
> > One poster claimed that Ada was not used in some embedded devices because of
> > memory overheads for exception handling.
>
> Sounds like nonsense, but it's not completely clear what that poster
> meant.

This is the exact text (and not my regurgutation of it which is vague).

--
[ ... ]

> This is what I meant with "worship". Of course you're right, it's almost
> sure, that there exists a C compiler for that hand-holdable device.
> But why there is _only_ a C compiler for it? And not Pascal? Or Ada?
> Perhaps even Java could be possible?

Pascal (or at least something that looks roughly like Pascal) would
be a reasonable possibility if everybody agreed exactly what that
"roughly like Pascal" language really ought to be.

Ada probably is not reasonable for _most_ such devices.  Ada requires
exception handling, which takes up quite a bit of memory.  In
embedded devices, price matters a LOT, and more memory means a higher
price.  Ada _does_ get used in embedded systems with budgets to
support it (e.g. the aerospace industry) but in the lower-end of the
market, exception handling makes it unusable (and the same goes for
C++).

Consider that at work right now, I'm working on some code for a PIC
16C55, which has a total of 512 bytes (no, not Kbytes, but bytes) of
program memory available.  It might be possible to get an Ada program
to run in that, but if so it'll take somebody a LOT smarter than me
to do it.

In addition, Ada is a large, complex language so porting it to a new
processor tends to be a relatively slow, expensive process.  If a
company has a choice between using C and waiting 6 months for an Ada
compiler to get finished, there's often little real choice at all.
--
-- Jerry Coffin on alt.os.development in post Re: using C to develop an OS
--




Chris Campbell

Re: Ada and embedded applications

[Jeffrey Carter]

Chris Campbell wrote [concerning a post about languages for hand-held
devices]:
> 
> This is the exact text (and not my regurgutation of it which is vague).
> 
> --
> [ ... ]
> Ada probably is not reasonable for _most_ such devices.  Ada requires
> exception handling, which takes up quite a bit of memory.  In
> embedded devices, price matters a LOT, and more memory means a higher
> price.  Ada _does_ get used in embedded systems with budgets to
> support it (e.g. the aerospace industry) but in the lower-end of the
> market, exception handling makes it unusable (and the same goes for
> C++).

So, write it in C, with hand-written code for all possible exceptions,
and in Ada, with exceptions and exception handlers, and see which one
"takes up" more memory. The Ada compiler can optimize a lot of the
overhead away, but the C compiler has no choice but to keep it in.

Or is it good to save a few bytes but have your app crash every third
time you run it? In that case Ada can be just as small as C.

-- 
Jeff Carter
"You tiny-brained wipers of other people's bottoms!"
Monty Python & the Holy Grail

Re: Ada and embedded applications

[Marin David Condic]

For something this small, you could probably code the app in assembler and
not find any good reasons to go to a higher level language. You probably
wouldn't get any big advantages using Ada for this sort of target anyway
(other than you're working with ther *coolest* language and one where the
syntax doesn't drive you crazy. :-) Any program that could be made to run in
512 bytes of memory could be coded in Ada, C or Assembler and be made just
about equally reliable with nearly equal effort. Its just too small a system
to think you need to worry much about code readability (throw it away and
rewrite it) or software reuse (are you going to port the app somewhere
else?) or runtime constraint checks or any of the other things where Ada
gives you an edge.

Something like this you toss to a single programmer and in a few days he
hands you back a working program that has been poured over pretty thoroughly
to make sure it works right. Where you want to work with Ada is where
programs become larger, data representations become more complex, the number
of developers is bigger, etc.

It would be *nice* if Ada was available for all sorts of microcontrollers
and the quality of the compilers made it possible to use Ada for such small
memory models. I believe that there is no reason that you couldn't write
code using a subset of Ada that would be able to fit in something this
small, but it requires some work on the part of the compiler vendor to
target that kind of platform. I just don't see anyone devoting much effort
to targeting that market.

MDC
--
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:c5TS6.23613$HL5.2796687@news6-win.server.ntlworld.com...
>
> Consider that at work right now, I'm working on some code for a PIC
> 16C55, which has a total of 512 bytes (no, not Kbytes, but bytes) of
> program memory available.  It might be possible to get an Ada program
> to run in that, but if so it'll take somebody a LOT smarter than me
> to do it.

Re: Ada and embedded applications

[Martin Dowie]

Chris Campbell <chris.danx@ntlworld.com> wrote in message
news:LTQS6.29382$%_1.5022327@news2-win.server.ntlworld.com...
> One poster claimed that Ada was not used in some embedded devices because
of
> memory overheads for exception handling.  Claiming it was used in embedded
> devices in industries that had budgets that supported it (e.g. the
aerospace
> industry).

Christ, I'd love a budget of any size! :-)

I'm using Ada (partly) because it will save us money!


> Is this correct or is it rubbish?  Also does exception handling in Ada
really
> have a large overhead?  (This is probably an implementation issue but is
their
> anything in the language that makes exception handling bulky?).

A few compilers I've come across offer 'zero cost' exception handling. By
this
they mean that it will have no affect on %CPU usage if there are no
exceptions.
The price you pay for that tends to be *slightly* slower exception handling
if/
when it does happen.

But really, is this guy designing a system that has exceptions happening in
a run-of-the-mill fashion? If so, he should forget what language it is
written
in and go back to the design...

Re: Ada and embedded applications

[John English]

Martin Dowie wrote:
> A few compilers I've come across offer 'zero cost' exception handling. By
> this
> they mean that it will have no affect on %CPU usage if there are no
> exceptions.
> The price you pay for that tends to be *slightly* slower exception handling
> if/
> when it does happen.

Hmm, the "obvious" way to handle exceptions involves one extra word
in the stack frame (a pointer to the start of the exception handling
code) which costs (typically) 4 bytes per handled block and 1 extra
word to pop on exit, which may or may not cost nothing, but is certainly
pretty cheap. For example, i386 processors have POPA/POPAD (pop all)
instructions, 680x0 have MOVEM (move multiple registers) where the
cost of an extra register is an extra memory cycle, and Vaxen of
fond memory had a word for the exception handler as a standard part
of the stack frame created by CALL.

Detecting exceptions can be more expensive -- e.g. on a processor that
doesn't generate an exception on arithmetic overflow, checking for
constraint errors can add quite a bit to the overall code cost.

The other complication is controlled types and the sequence of object
destruction that block exit can entail.

Does anyone have any references to alternative ways of implementing
exception handling?

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.comp.it.bton.ac.uk/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: Ada and embedded applications

[Robert A Duff]

John English <je@brighton.ac.uk> writes:

> Hmm, the "obvious" way to handle exceptions involves one extra word
> in the stack frame (a pointer to the start of the exception handling
> code) which costs (typically) 4 bytes per handled block and 1 extra
> word to pop on exit, which may or may not cost nothing, but is certainly
> pretty cheap.

But the more desirable implementation is to save the small cost of
setting that pointer, and spend perhaps 10,000 instructions searching a
table of code addresses when an exception is raised.  If exceptions
being raised are rare, but blocks protected by exception handlers are
more common, that's a win.

> Does anyone have any references to alternative ways of implementing
> exception handling?

One variant of the code-table technique was decribed in the Ada 83
rationale.  The implementation you described above is essentially
equivalent to the VAX/VMS standard method.  I don't have other
references at hand, but surely a lot of this stuff is common lore, and
documented somewhere.

- Bob

Re: Ada and embedded applications

[Ehud Lamm]

Robert A Duff <bobduff@world.std.com> wrote in message >
> But the more desirable implementation is to save the small cost of
> setting that pointer, and spend perhaps 10,000 instructions searching a
> table of code addresses when an exception is raised.  If exceptions
> being raised are rare, but blocks protected by exception handlers are
> more common, that's a win.
>

Some insight may be gained from looking at system.exceptions and
ada.exceptions in the Gnat distribution.


--
Ehud Lamm   mslamm@mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <==  Me!

Re: Ada and embedded applications

[Pat Rogers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]


"Robert A Duff" <bobduff@world.std.com> wrote in message
news:wccvgm6bk7b.fsf@world.std.com...
> John English <je@brighton.ac.uk> writes:
>
> > Hmm, the "obvious" way to handle exceptions involves one extra word
> > in the stack frame (a pointer to the start of the exception handling
> > code) which costs (typically) 4 bytes per handled block and 1 extra
> > word to pop on exit, which may or may not cost nothing, but is certainly
> > pretty cheap.
>
> But the more desirable implementation is to save the small cost of
> setting that pointer, and spend perhaps 10,000 instructions searching a
> table of code addresses when an exception is raised.  If exceptions
> being raised are rare, but blocks protected by exception handlers are
> more common, that's a win.
>
> > Does anyone have any references to alternative ways of implementing
> > exception handling?
>
> One variant of the code-table technique was decribed in the Ada 83
> rationale.  The implementation you described above is essentially
> equivalent to the VAX/VMS standard method.  I don't have other
> references at hand, but surely a lot of this stuff is common lore, and
> documented somewhere.

T. P. Baker and G. A. Riccardi, �Implementing Ada Exceptions,� IEEE
Software, vol. 3, no. 5, pp. 42-51, 1986.

Re: Ada and embedded applications

[Ken Garlington]

"Chris Campbell" <chris.danx@ntlworld.com> wrote in message
news:LTQS6.29382$%_1.5022327@news2-win.server.ntlworld.com...
: Hi,
:
: On another group a discussion about various languages errupted and it took
a
: while to get anything positive out of it(it's started as the old "my
language is
: best" debate).  Now the discussion seems to be focussed on distance from
: hardware, like C being relatively close to hardware.  This is largely
irrelevant
: background.
:
: One poster claimed that Ada was not used in some embedded devices because
of
: memory overheads for exception handling.  Claiming it was used in embedded
: devices in industries that had budgets that supported it (e.g. the
aerospace
: industry).
:
: Is this correct or is it rubbish?

Rubbish.

: Also does exception handling in Ada really
: have a large overhead?  (This is probably an implementation issue but is
their
: anything in the language that makes exception handling bulky?).

Not for most of the embedded Ada code I've written.

Re: Ada and embedded applications

[Chris Campbell]

> : One poster claimed that Ada was not used in some embedded devices because
> of
> : memory overheads for exception handling.  Claiming it was used in embedded
> : devices in industries that had budgets that supported it (e.g. the
> aerospace
> : industry).
> :
> : Is this correct or is it rubbish?
>
> Rubbish.

> : Also does exception handling in Ada really
> : have a large overhead?  (This is probably an implementation issue but is
> their
> : anything in the language that makes exception handling bulky?).
>
> Not for most of the embedded Ada code I've written.

Maybe this posters views where based on the fact that the last time he used Ada
was in 1983 and it was a Janus compiler (i.e. Ada was relatively new and
compiler technology less advanced than it is today).









Chris Campbell

Re: Ada and embedded applications

[Marin David Condic]

If that's the case, yeah, he's operating on ancient information. Lots of the
early compilers were very bad. This is the classic case of people evaluating
a language based on a particular compiler rather than on the basis of the
syntax & semantics of the language. Really smart people fall into this trap
surprisingly often. In a way, its inevitable because you can't write
real-world code using a theoretic compiler. If all the language
implementations are bad, its hard not to conclude that the language itself
is bad - or that it doesn't matter how "good" it *might* be one day.

I'd suggest you recommend he try writing some code in Ada using a more
modern compiler & that he learn something about pragma Supress, etc. If you
want efficient code, you *must* learn the language thoroughly & understand
your compiler.

MDC
--
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:hfoT6.11877$fs6.656133@news6-win.server.ntlworld.com...
> Maybe this posters views where based on the fact that the last time he
used Ada
> was in 1983 and it was a Janus compiler (i.e. Ada was relatively new and
> compiler technology less advanced than it is today).

Re: Ada and embedded applications

[Jerry van Dijk]

"Chris Campbell" <chris.danx@ntlworld.com> writes:


> Maybe this posters views where based on the fact that the last time he used Ada
> was in 1983 and it was a Janus compiler (i.e. Ada was relatively new and
> compiler technology less advanced than it is today).

Given that the poster was Jerry Coffin, that sounds very unlikely.

-- 
--  Jerry van Dijk   | email: jvandyk@attglobal.net
--  Leiden, Holland  | web:   home.trouwweb.nl/Jerry

Re: Ada and embedded applications

[Chris Campbell]

"Jerry van Dijk" <jvandyk@attglobal.net> wrote in message
news:uae3l4hkl.fsf@attglobal.net...
> "Chris Campbell" <chris.danx@ntlworld.com> writes:
>
>
> > Maybe this posters views where based on the fact that the last time he used
Ada
> > was in 1983 and it was a Janus compiler (i.e. Ada was relatively new and
> > compiler technology less advanced than it is today).
>
> Given that the poster was Jerry Coffin, that sounds very unlikely.

Why?  I'm sure he stated that in one of his most recent posts to alt.os.dev.


Chris

Re: Ada and embedded applications

[Chris Campbell]

> > > Maybe this posters views where based on the fact that the last time he
used
> Ada
> > > was in 1983 and it was a Janus compiler (i.e. Ada was relatively new and
> > > compiler technology less advanced than it is today).
> >
> > Given that the poster was Jerry Coffin, that sounds very unlikely.
>
> Why?  I'm sure he stated that in one of his most recent posts to alt.os.dev.

I take it back, part of the post i miss read and now i've checked it and it's
not true.  He has used GNAT and some others.  Sorry Jerry, my mistake.


Chris Campbell

Re: Ada and embedded applications

[Marin David Condic]

I think a more prudent answer would be "It Depends". Considering that it is
possible to generate programs that will need lots of constraint checking at
runtime & constraint errors are sort of part of exception handling, one
might conclude that exception handling can cost a significant part of the
budget due to code bloat & runtime inefficiencies. (This may be from whence
the original "rubbish" came from - a misunderstanding of the *necessity* of
doing all this checking.)

The other side of exception processing is that you can easily turn off
checking & run without a net. At that point, exception processing should be
at or near 0 as part of the memory/CPU budget.

I've done embedded stuff where leaving in runtime error checking would have
killed the project. In a sense this is "inherent in the language" because
Ada requires that the checks be done for validation. In another sense it is
not inherent because the language provides means of disabling the checks
when speed/space is an issue. So it is fair to say that exception processing
*can* impose a significant overhead, but *need not*, provided you understand
what you are doing.

MDC
--
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/


"Ken Garlington" <Ken.Garlington@computer.org> wrote in message
news:JBgT6.1923$E6.322615411@newssvr16.news.prodigy.com...
> : Also does exception handling in Ada really
> : have a large overhead?  (This is probably an implementation issue but is
> their
> : anything in the language that makes exception handling bulky?).
>
> Not for most of the embedded Ada code I've written.
>
>