minimal hardware for ada (newbie)

minimal hardware for ada (newbie)

[Michael Viotto]

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

Stumbling over Ada in a long thread in comp.arch.embedded I got
interested in that language. I  have some very simple (?) questions. 

Which is the minimal hardware requirement for running Ada on an
embedded system? The "smallest" processor I found was a 386. Are 16-
or even 8-bit processors supported, too? If so, what real time kernels
can be used together with ada?

Any hints are welcome!

Michael Viotto






Institut fuer Solare Energieversorgungstechnik (ISET) e.V.
K�nigstor 59  34119 Kassel Tel: 0561/7294-219   Fax: -100
m.viotto@iset.uni-kassel.de    www.iset.uni-kassel.de

Re: minimal hardware for ada (newbie)

[Tucker Taft]

Michael Viotto wrote:
> 
> Stumbling over Ada in a long thread in comp.arch.embedded I got
> interested in that language. I  have some very simple (?) questions.
> 
> Which is the minimal hardware requirement for running Ada on an
> embedded system? The "smallest" processor I found was a 386. Are 16-
> or even 8-bit processors supported, too? If so, what real time kernels
> can be used together with ada?

We have developed (and recently validated) a version of our
AdaMagic technology which uses optimized ANSI C as its intermediate 
representation.  One of the reasons was to allow a programming team to
write their source code in Ada, while relying only on the availability
of an ANSI C compiler for their chosen target.  We also have
a version of the Ada run-time that at the lowest level depends
only on routines included in the standard ANSI C run-time.

The Ada variable and subprogram names are preserved in the
generated C, and additional "#line" information is provided,
so that it is feasible to use a C debugger to debug at the
Ada source level using this technology.

So it is possible to run Ada on essentially any chip where
a C compiler exists.  However, if you use all of the features
of the run-time, you would probably run out of memory space,
so you would have to avoid features which require a lot of
run-time support (such as rendezvous, full Text_IO, etc.).

> Any hints are welcome!
> 
> Michael Viotto
> 
> Institut fuer Solare Energieversorgungstechnik (ISET) e.V.
> K�nigstor 59  34119 Kassel Tel: 0561/7294-219   Fax: -100
> m.viotto@iset.uni-kassel.de    www.iset.uni-kassel.de

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: minimal hardware for ada (newbie)

[Niklas Holsti]

Tucker Taft wrote:
> 
> We have developed (and recently validated) a version of our
> AdaMagic technology which uses optimized ANSI C as its intermediate
> representation.  One of the reasons was to allow a programming team to
> write their source code in Ada, while relying only on the availability
> of an ANSI C compiler for their chosen target.  We also have
> a version of the Ada run-time that at the lowest level depends
> only on routines included in the standard ANSI C run-time.

I'm working on an I8051 program to control a space-based instrument,
and have again experienced the pain of working in C. Using
AdaMagic-to-C would have been nice, however I think it would
only be practical if one can make the C code use the typical
I8051 C extensions to ANSI C, such as controlling the memory space
for each variable. In Keil C51, for example, one of the new
keywords 'data', 'idata', 'pdata' or 'xdata' is placed in the
variable declaration between the type-id and the variable-id
to determine the memory space.

While one could implement one's own postprocessor to mutilate the
C code in this way, it would be simpler and safer to make the
necessary annotations in the Ada code, perhaps as pragmas on
the variables or types. Does AdaMagic provide anything like this?

Moreover, given the limited architecture of the I8051, it seems
unlikely that a run-time using only ANSI C routines could perform
within an order of magnitude of a kernel designed for the
I8051. Any data on this? For example, how does your ANSI-C-based
run-time handle the stack when switching tasks?

TIA

Niklas Holsti
Working at but not speaking for Space Systems Finland Ltd.

Re: minimal hardware for ada (newbie)

[Tucker Taft]

Niklas Holsti wrote:
> 
> Tucker Taft wrote:
> >
> > We have developed (and recently validated) a version of our
> > AdaMagic technology which uses optimized ANSI C as its intermediate
> > representation.  One of the reasons was to allow a programming team to
> > write their source code in Ada, while relying only on the availability
> > of an ANSI C compiler for their chosen target.  We also have
> > a version of the Ada run-time that at the lowest level depends
> > only on routines included in the standard ANSI C run-time.
> 
> I'm working on an I8051 program to control a space-based instrument,
> and have again experienced the pain of working in C. Using
> AdaMagic-to-C would have been nice, however I think it would
> only be practical if one can make the C code use the typical
> I8051 C extensions to ANSI C, such as controlling the memory space
> for each variable. In Keil C51, for example, one of the new
> keywords 'data', 'idata', 'pdata' or 'xdata' is placed in the
> variable declaration between the type-id and the variable-id
> to determine the memory space.
> 
> While one could implement one's own postprocessor to mutilate the
> C code in this way, it would be simpler and safer to make the
> necessary annotations in the Ada code, perhaps as pragmas on
> the variables or types. Does AdaMagic provide anything like this?

Not currently, though using pragma "Convention" for this might
make sense.  We have looked into something like this for a digital
signal processor which has two memory spaces.  Because we are
generating C source as the intermediate, it is a relatively small
effort to add this kind of thing.  By constrast, if we were generating 
machine code directly, it would obviously be a big deal to add support
for multiple memory spaces.

> Moreover, given the limited architecture of the I8051, it seems
> unlikely that a run-time using only ANSI C routines could perform
> within an order of magnitude of a kernel designed for the
> I8051. Any data on this? For example, how does your ANSI-C-based
> run-time handle the stack when switching tasks?

The run-time is in two layers, the upper layer is written
in Ada, and is fully portable between targets.  The lower layer
is also mostly written in Ada, with a bit of assembler or
C thrown in, and multiple versions exist, depending on the underlying
kernel.  The "pure C" version makes use of setjmp/longjmp for
task stack switching.  Other versions use the thread primitives provided
by the underlying kernel.

> TIA
> 
> Niklas Holsti
> Working at but not speaking for Space Systems Finland Ltd.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: minimal hardware for ada (newbie)

[Tom Moran]

>The "smallest" processor I found was a 386. Are 16-
>or even 8-bit processors supported, too?
Certainly there were Ada 83 compilers targetted to 16 bit 8086
embedded systems.  I haven't kept up to date with more recent stuff
though.

Re: minimal hardware for ada (newbie)

[Richard D Riehle]

>The "smallest" processor I found was a 386. Are 16-
>or even 8-bit processors supported, too?

 RR Software once had an Ada 83 compiler, absent tasking
 as I recall, for the Z-80.  It is rather unlikely anyone
 would easily produce a full Ada 95 compiler for most of
 the eight bit machines.  In particular, I do not expect
 to ever see an Ada 95 compiler for the I8051. It is not
 practical, and probably not feasible.

 This is pure conjecture, I suppose.  I know some of the
 GNAT folks disagree with me about the feasibility of Ada
 (1995 standard) on the I8051.  We will probably never know
 about this since no one is taking the trouble to do the port. 

 On the other hand, if someone is talking about a subset of
 Ada, I think that would be both feasible and technically
 desirable. The compile time checking alone would be of benefit
 for many of the applications (especially medical devices) for
 which the I8051 is used. 

 It is probably not economically attractive to port Ada to,
 the eight-bitters, and persuading I8051 programmers to use Ada,
 even  a subset, would be a sales job that would make cleaning the
 Augean stables seem like spring housekeeping.  

 Richard Riehle
 richard@adaworks.com
 http://www.adaworks.com