Tips for realtime embedded Ada?

Tips for realtime embedded Ada?

[John Gluth]

Howdy,

I'm looking for wisdom regarding designing software for a realtime
embedded application.

Can you suggest constructs, design philosophies, etc. to use/avoid
to avoid inefficient code?

I realise that a lot of this will be compiler/platform dependent
(looks like we'll be going Rational/PowerPC, but not sure yet),
but any general tips you can suggest would be greatly appreciated.

Thx,

John
jpgluth@ccgate.hac.com

P.S. Not using Ada is not an option, for the smart-alecks out there...
;-)

Re: Tips for realtime embedded Ada?

[Stephen M. Garriga]

John Gluth <jpGluth@ccgate.hac.com> wrote:

>>Howdy,

>>I'm looking for wisdom regarding designing software for a realtime
>>embedded application.

{snip}

>>P.S. Not using Ada is not an option, for the smart-alecks out there...
>>;-)

Not at all?

My experience in Ada83 on Dec Alpha and IBM RS6000 H/W has been that
standard Ada I/O implementations are _VERY_SLOW_ - writing wrappers
which pragma interface to C library functions can often give huge
performance increases especially if the OS provides 
asynchonous i/o facilities for C.


Steve Garriga                         garrigas@logica.com                 
   type OPINION is access PERSONAL_THOUGHTS_AND_BIAS; 
   OPINION_STATED : new OPINION := not LOGICA.OPINION;
Logica UK Ltd.   +44 171 637 9111   http://www.logica.com

Re: Tips for realtime embedded Ada?

[Tom Griest]

John Gluth <jpGluth@ccgate.hac.com> writes:

>I'm looking for wisdom regarding designing software for a realtime
>embedded application.
>
>Can you suggest constructs, design philosophies, etc. to use/avoid
>to avoid inefficient code?

If you have the flexibility to use Ada95, take a look at the real-time 
annex.  In genneral, you want to avoid a design that results in very
large numbers of simultaneous tasks unless you have parallel hardware
which takes advantage of the parallelism.

The Keep It Simple philosophy is usually best for real-time.  Add
complexity only when it buys you a big win in requirements relief.
For example, you might add timestamping and extrapolation if it
relaxes the requirement on sampling period stability and therefore
becomes more tolerant of interrupt jitter.

A netnews article is not the best place to go into all the details,
and that's why there are several books on this subject.  I can
recommend books by either Andy Wellings or Alan Burns, but I'm sure
there are many other good books out there too.

-Tom

Re: Tips for realtime embedded Ada?

[Pat Rogers]

>John Gluth <jpGluth@ccgate.hac.com> writes:
>
>I'm looking for wisdom regarding designing software for a realtime
>embedded application.
>
>Can you suggest constructs, design philosophies, etc. to use/avoid
>to avoid inefficient code?

If you are using Ada83, have a look at the ARTEWG CIFO and other
ARTEWG products. They will go a long way towards "educating" you.
Last I heard they were on the AdaIC.

---------------
Patrick Rogers
progers@acm.org

Re: Tips for realtime embedded Ada?

[Daryl Siddon]

John Gluth wrote:
> 
> Howdy,
> 
> I'm looking for wisdom regarding designing software for a realtime
> embedded application.
> 
> Can you suggest constructs, design philosophies, etc. to use/avoid
> to avoid inefficient code?
> 
> I realise that a lot of this will be compiler/platform dependent
> (looks like we'll be going Rational/PowerPC, but not sure yet),
> but any general tips you can suggest would be greatly appreciated.
> 
> Thx,
> 
> John
> jpgluth@ccgate.hac.com
> 
> P.S. Not using Ada is not an option, for the smart-alecks out there...
> ;-)

You can find a wealth of information by searching the WEB with a 
search engine (http://www.search.com then use the "excite" search 
engine with keyword="embedded").

Daryl Siddon

Re: Tips for realtime embedded Ada?

[Alan Brain]

John Gluth <jpGluth@ccgate.hac.com> wrote:
>Howdy,
>
>I'm looking for wisdom regarding designing software for a realtime
>embedded application.
>
>Can you suggest constructs, design philosophies, etc. to use/avoid
>to avoid inefficient code?
>
>I realise that a lot of this will be compiler/platform dependent
>(looks like we'll be going Rational/PowerPC, but not sure yet),
>but any general tips you can suggest would be greatly appreciated.

You mentioned 'Inneficient' - so I have assumed you want Best Possible 
performance, and Maintainability, Ease of Construction etc is secondary.

1) Don't use Tasking except as a Guardian of resources. Very few 
compilers do context-switching efficiently. Write a scheduler in 
assembler, or if you can, microcode.

2) The difference between efficiency of compiled code can be radically 
affected by the compiler you're using, and the version thereof. A 1994 
vintage Ada 83 compiler will in my experience almost always generate much 
more efficient code than a 1990 ANSI C Compiler - but the converse holds 
true too. Thus the decision on whether to go for 100% Ada, or 80% with 
lots of pragma interfaces to C libraries, is intimately tied in with the 
exact compiler(s) you're using.

3) Keep it simple.

4) Design cleanly: Then go through with the performance analyser, trying 
to find the areas most often executed: often 100 hours of work here to 
save 2 machine cycles gives far better results than spending 1000 hours 
to save 2000 cycles elsewhere.

FWIW, I've had really time-critical applications where much skull sweat 
was spent deciding whether to implement a bespoke scheduler, how much was 
to be in assembler, how much in C, whether to use Ada at all etc. I 
convinced management we needed a 'proof-of-principle' using a clean, 
unoptimised design in Ada first, with all checking mechanisms left in.

It exceeded the specified speed by 14% at the first attempt, saving about 
two million bucks, because all estimations had been done with a 1984 
model Ada compiler vs a 1989 model C compiler, and we used a 1992 model 
Aad compiler from a different vendor. Hence 3) above.  

Re: Tips for realtime embedded Ada?

[Bob Kitzberger]

Alan Brain (aebrain@dynamite.com.au) wrote:

: 1) Don't use Tasking except as a Guardian of resources. Very few 
: compilers do context-switching efficiently. Write a scheduler in 
: assembler, or if you can, microcode.

I would suggest that you first check the PIWG tasking benchmark
results, and study the vendor's documentation on tasking, before
throwing out the baby with the bathwater.  "Passive tasking
optimizations", performed by some vendors, can reduce context
switching time by an order of magnitude, to the level of
user-written semaphore-protected regions.  Being able to specify
concurrent behavior at the language level is very useful, so
make sure you know what you're giving up, and why, before you
run off and write your own scheduler.

A good strategy to use is to hide your concurrent objects/classes
within a package body -- never export a task via the package
specification.  You can use Ada tasking (encapsulated in the package
body) during development, and if you ever need to replace the Ada task
with something lower-level, for whatever reason, you can replace the
body of the package without changing any clients (alter this strategy
as appropriate for time-sliced applications, event-driven, etc.)

--
Bob Kitzberger	      Rational Software Corporation       rlk@rational.com

Re: Tips for realtime embedded Ada?

[Greg Bond]

Bob Kitzberger wrote:
> 
> Alan Brain (aebrain@dynamite.com.au) wrote:
> 
> : 1) Don't use Tasking except as a Guardian of resources. Very few
> : compilers do context-switching efficiently. Write a scheduler in
> : assembler, or if you can, microcode.
> 
> I would suggest that you first check the PIWG tasking benchmark
> results, and study the vendor's documentation on tasking, before
> throwing out the baby with the bathwater.  "Passive tasking
> optimizations", performed by some vendors, can reduce context
> switching time by an order of magnitude, to the level of
> user-written semaphore-protected regions.  Being able to specify
> concurrent behavior at the language level is very useful, so
> make sure you know what you're giving up, and why, before you
> run off and write your own scheduler.

<stuff deleted>

In fact, Ada 95's protected objects (like Posix..4a monitors/condition 
variables only better) can be implemented so that they they involve 
fewer lock/unlock operations, and fewer context switches than an 
equivalent semaphore-based implementation. In addition, if priority 
ceiling locking is used (also Posix.4a/Ada 95), lock/unlock operations 
do not have to use queueing which further improves performance.

---
* Greg Bond                         * Dept. of Electrical Eng.  
* email: bond@ee.ubc.ca             * Univ. of British Columbia      
* voice: (604) 822 0899             * 2356 Main Mall                 
* fax:   (604) 822 5949             * Vancouver, BC              
* web: http://www.ee.ubc.ca/~bond   * Canada, V6T 1Z4