Is it possible to build an Ada cross-compiler for an 8-bit embedded target now that gcc 3.X has support for Ada?

Is it possible to build an Ada cross-compiler for an 8-bit embedded target now that gcc 3.X has support for Ada?

[Peter Milliken]

Subject pretty much says it all.

Now that you can build an Ada compiler using gcc 3.X (well, according to the
build instructions of gcc 3.x :-)), I began to wonder whether it was
possible to build a cross-compiler for an 8-bit target processor. The 8-bit
processor family in question is already supported by gcc (I believe).

When I say "possible", I just mean "follow the cross-compiling instructions
and out pops an Ada compiler" - I don't mean, "spend months of work patching
various files and then you might have an Ada compiler" :-)

I would dearly like to convince some managers here that Ada is a reasonable
alternative to C/C++ for product development. I don't mind spending a lot of
my own time re-writing my current C code in Ada to help prove the point, but
I need the tools to at least contemplate giving it a go :-).

The cross-compiler would be built and run on a Windoze box (just answering
(one of) the obvious questions :-)).

Thanks
Peter

Re: Is it possible to build an Ada cross-compiler for an 8-bit embedded target now that gcc 3.X has support for Ada?

[Peter Milliken]

I just came across Rolf's porting efforts for getting Ada/gnat runing on an
AVR processor (http://sourceforge.net/projects/avr-ada/) - so the question
is answered. It is not straight forward or easy at all.

Looks like I'll have to wait even longer before I can get a vehicle that
will help convince management............


"Peter Milliken" <peterm@resmed.com.au> wrote in message
news:zgRsb.200$co2.10332@nnrp1.ozemail.com.au...
> Subject pretty much says it all.
>
> Now that you can build an Ada compiler using gcc 3.X (well, according to
the
> build instructions of gcc 3.x :-)), I began to wonder whether it was
> possible to build a cross-compiler for an 8-bit target processor. The
8-bit
> processor family in question is already supported by gcc (I believe).
>
> When I say "possible", I just mean "follow the cross-compiling
instructions
> and out pops an Ada compiler" - I don't mean, "spend months of work
patching
> various files and then you might have an Ada compiler" :-)
>
> I would dearly like to convince some managers here that Ada is a
reasonable
> alternative to C/C++ for product development. I don't mind spending a lot
of
> my own time re-writing my current C code in Ada to help prove the point,
but
> I need the tools to at least contemplate giving it a go :-).
>
> The cross-compiler would be built and run on a Windoze box (just answering
> (one of) the obvious questions :-)).
>
> Thanks
> Peter
>
>
>
>
>

Re: Is it possible to build an Ada cross-compiler for an 8-bit embedded target now that gcc 3.X has support for Ada?

[Peter Amey]

Peter Milliken wrote:
 > Subject pretty much says it all.
 >
 > Now that you can build an Ada compiler using gcc 3.X (well, according 
to the
 > build instructions of gcc 3.x :-)), I began to wonder whether it was
 > possible to build a cross-compiler for an 8-bit target processor. The 
8-bit
 > processor family in question is already supported by gcc (I believe).

Peter,

Given that there is already a C compiler for your target, one approach 
might be to _design_ in Ada and then use an Ada->C compiler/translator 
to convert the design to C for compilation.  In practice you can tie the 
translator and C compiler so tightly together that it looks like an Ada 
compiler.

The biggest problem with this approach in general is the size of the 
run-time library you need to support all of Ada (esp. tasking, exception 
handling etc.) and writing such a library for a small processor.  We 
have had some success in avoiding these problems by using SPARK as the 
design language.  This gives several benefits:

1. SPARK is designed to need zero (or at least very little) run-time 
library support so all the generated C is directly and easily traceable 
back to some SPARK source statement.

2.  Using the SPARK tools you can easily prove the code to be exception 
free (e.g. no range violations) and this means the translation can be 
greatly simplified because it does not have to include the run-time 
checks that a full Ada compiler would place in the code.  The SPARK 
tools can be told how big your C int is, for example, and can ensure 
there are no overflows in the translated code.

3.  You can do a great deal of strong verification on the SPARK "design 
model" before generating the C and therefore greatly reduce the cost of 
the testing process.

We have submitted a paper to Ada Europe 2004 on this topic.

regards

Peter

------------------------------------------------------------
Peter Amey                              Principal Consultant

Praxis Critical Systems
20, Manvers St.                         +44 (0)1225 466991
Bath                                    www.praxis-cs.co.uk
BA1 1PX                                 www.sparkada.com
------------------------------------------------------------

Re: Is it possible to build an Ada cross-compiler for an 8-bit embedded target now that gcc 3.X has support for Ada?

[Mike Silva]

Peter Amey <peter.amey@praxis-cs.co.uk> wrote in message news:<bp28mb$1iodo4$1@ID-69815.news.uni-berlin.de>...
> 
> The biggest problem with this approach in general is the size of the 
> run-time library you need to support all of Ada (esp. tasking, exception 
> handling etc.) and writing such a library for a small processor.  We 
> have had some success in avoiding these problems by using SPARK as the 
> design language.  This gives several benefits:

That's a very interesting approach to the problem!  SPARK Ravenscar
would be an obvious and excellent next step, it seems.

I wonder what percentage of 8 and 16 bit software uses tasks?

Re: Is it possible to build an Ada cross-compiler for an 8-bit embedded target now that gcc 3.X has support for Ada?

[Martin Dowie]

"Mike Silva" <snarflemike@yahoo.com> wrote in message
news:20619edc.0311141059.3db2de83@posting.google.com...
> Peter Amey <peter.amey@praxis-cs.co.uk> wrote in message
news:<bp28mb$1iodo4$1@ID-69815.news.uni-berlin.de>...
> >
> > The biggest problem with this approach in general is the size of the
> > run-time library you need to support all of Ada (esp. tasking, exception
> > handling etc.) and writing such a library for a small processor.  We
> > have had some success in avoiding these problems by using SPARK as the
> > design language.  This gives several benefits:
>
> That's a very interesting approach to the problem!  SPARK Ravenscar
> would be an obvious and excellent next step, it seems.

Anyone know of a SPARK-ed RTK?..

Re: Is it possible to build an Ada cross-compiler for an 8-bit embedded target now that gcc 3.X has support for Ada?

[Randy Brukardt]

"Peter Milliken" <peterm@resmed.com.au> wrote in message
news:zgRsb.200$co2.10332@nnrp1.ozemail.com.au...
> Subject pretty much says it all.
>
> Now that you can build an Ada compiler using gcc 3.X (well, according to
the
> build instructions of gcc 3.x :-)), I began to wonder whether it was
> possible to build a cross-compiler for an 8-bit target processor. The
8-bit
> processor family in question is already supported by gcc (I believe).
>
> When I say "possible", I just mean "follow the cross-compiling
instructions
> and out pops an Ada compiler" - I don't mean, "spend months of work
patching
> various files and then you might have an Ada compiler" :-)

To not answer your actual question at all, but...

As someone else pointed out, the biggest cost/overhead is porting the
runtime libraries. Speaking for Janus/Ada, porting the code
generator/compiler usually only takes a month or so (and that's for building
a code generator from scratch). But building the basic runtime support for
exceptions, tasking, floating point (which usually has to be emulated on
small processors), etc. can take a lot of time. In addition, that support
can make programs quite large.

Because of this, I think you'd have trouble making acceptable programs with
a general-purpose compiler like GCC.

Janus/Ada was originally built for Z-80 and 8086 processors without much
memory. Thus, we only load floating point and tasking support when they are
used. That isn't very valuable on standard systems like Windows these days,
but it matters a lot on 8-bit systems.

The only reason that we don't support 8-bit processors is a lack of demand.
Everyone seems to use a different processor, and thus we cannot really
justify the investment building code generators (easy) and runtime libraries
(not as easy) for each one.

Of course, we're always interested in customization projects, but that won't
help you convince your manager...

                   Randy Brukardt

Re: Is it possible to build an Ada cross-compiler for an 8-bit embedded target now that gcc 3.X has support for Ada?

[Stephen Leake]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Peter Milliken" <peterm@resmed.com.au> wrote in message
> news:zgRsb.200$co2.10332@nnrp1.ozemail.com.au...
> >
> > Now that you can build an Ada compiler using gcc 3.X (well,
> > according to the build instructions of gcc 3.x :-)), I began to
> > wonder whether it was possible to build a cross-compiler for an
> > 8-bit target processor. The 8-bit processor family in question is
> > already supported by gcc (I believe).
> >
> > When I say "possible", I just mean "follow the cross-compiling
> > instructions and out pops an Ada compiler" - I don't mean, "spend
> > months of work patching various files and then you might have an
> > Ada compiler" :-)
> 
> To not answer your actual question at all, but...
> 
> As someone else pointed out, the biggest cost/overhead is porting the
> runtime libraries. 

Note that the "no runtime" subset of Ada is still a _far_ better
language than C. So it is worth persuing, since you already have the
code-generation part in the gcc back end. The result won't be "Ada",
but it will be a very useful subset.

GNAT provides a "pragma No_Runtime", which reports errors for any code
that would use the runtime, so you can tell when you need to change
the code.

-- 
-- Stephe

Re: Is it possible to build an Ada cross-compiler for an 8-bit embedded target now that gcc 3.X has support for Ada?

[Randy Brukardt]

"Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
news:uptfp3bpu.fsf@nasa.gov...
> Note that the "no runtime" subset of Ada is still a _far_ better
> language than C. So it is worth persuing, since you already have the
> code-generation part in the gcc back end. The result won't be "Ada",
> but it will be a very useful subset.
>
> GNAT provides a "pragma No_Runtime", which reports errors for any code
> that would use the runtime, so you can tell when you need to change
> the code.

I'm a bit suspicious of this claim, mainly because you'd have to run with
checks suppressed in order to avoid use of the runtime. (Handling/reporting
any failure, even to abort the program, would require some sort of runtime.
Just stopping the program with no indication of why doesn't need any
runtime, but its just as useful as running with checks suppressed.) Runtime
checking is a very important part of Ada, (and one which doesn't add much
overhead in general), and running without it would seem to be writing C with
Ada syntax. After all, it's basic exception handling that makes Ada programs
so bullet-proof. (The AdaIC webserver has yet to log any downtime related to
the program itself - all downtime has been hardware or OS failures.)

                          Randy.

Re: Is it possible to build an Ada cross-compiler for an 8-bit embedded target now that gcc 3.X has support for Ada?

[Stephen Leake]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
> news:uptfp3bpu.fsf@nasa.gov...
> > Note that the "no runtime" subset of Ada is still a _far_ better
> > language than C. So it is worth persuing, since you already have the
> > code-generation part in the gcc back end. The result won't be "Ada",
> > but it will be a very useful subset.
> >
> > GNAT provides a "pragma No_Runtime", which reports errors for any code
> > that would use the runtime, so you can tell when you need to change
> > the code.
> 
> I'm a bit suspicious of this claim, mainly because you'd have to run with
> checks suppressed in order to avoid use of the runtime. 

I have code for a spacecraft that uses "pragma No_Runtime", and does
_not_ include the GNAT runtime in the link (I don't have a GNAT
runtime that compiles for this processor/OS combination :).

"pragma No_Runtime" isn't in the standard GNAT manual, so I can't
check whether it implies "suppress all checks"; it may.

But that's ok; we run with checks suppressed for the final flight code
anyway; we've already tested everything, and all checks that are
needed are done explicitly, to make them visible to reviewers.

> (Handling/reporting any failure, even to abort the program, would
> require some sort of runtime. Just stopping the program with no
> indication of why doesn't need any runtime, but its just as useful
> as running with checks suppressed.) 

Right.

> Runtime checking is a very important part of Ada, 

Only during the unit test phase. I run the unit tests on a different
processor with checks on; that catches logic errors. It would be nice
to repeat the tests on the target processor still with checks on, but
that only catches compiler bugs or implementation-dependent code;
runtime checks are not very helpful there.

> (and one which doesn't add much overhead in general), and running
> without it would seem to be writing C with Ada syntax.

Even writing "C with Ada syntax" is _way_ better than writing "C with
C syntax". That was my original point. You get namespace control with
packages, named association in aggregates and function calls, nested
procedures, generics; lots of really good stuff.

> After all, it's basic exception handling that makes Ada programs so
> bullet-proof. 

That's only one aspect. Compile time type checking, and the other
features I mentioned above, are also important.

I agree "no runtime Ada" is not as good as "full Ada". But it is
very much better than C.

> (The AdaIC webserver has yet to log any downtime related to the
> program itself - all downtime has been hardware or OS failures.)

Which is a consequence of good design. How many times has it caught an
exception generated by a runtime check? I would class those as "bugs",
even if they don't cause lots of downtime.

-- 
-- Stephe

Re: Is it possible to build an Ada cross-compiler for an 8-bit embedded target now that gcc 3.X has support for Ada?

[Randy Brukardt]

"Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
news:ubrr91g7a.fsf@nasa.gov...
> Which is a consequence of good design. How many times has it caught an
> exception generated by a runtime check? I would class those as "bugs",
> even if they don't cause lots of downtime.

Many times, tracable to 4 or 5 actual bugs (all fixed now). The point is
that even bugs don't cause the program to fail or (worse) cause a security
hole. Testing can never prove the absense of bugs; unless you're using
SPARK, you have to assume there are still some in there.

                   Randy.

Re: Is it possible to build an Ada cross-compiler for an 8-bit embedded target now that gcc 3.X has support for Ada?

[Chad R. Meiners]

"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:vrnjndmn0vqge6@corp.supernews.com...
> Testing can never prove the absense of bugs; unless you're using
> SPARK, you have to assume there are still some in there.

Well non-exhaustive testing cannot prove the absense of bugs ;)
Furthermore, SPARK can only guaruntee the absence of certain bugs (problem
specification errors are outside of SPARK's scope).  Thus, it is always safe
to assume that there are bugs in your software.  ;-)

Re: Is it possible to build an Ada cross-compiler for an 8-bit embedded target now that gcc 3.X has support for Ada?

[Peter Milliken]

In the initial case, I wouldn't be that interested in tasking or floating
point support. I would like exception handling and run-time checking though
:-)

My current application space is of the order of 8K so my "needs" are fairly
modest from the perspective of Ada features. Whilst I know people have tiny
OS's and "tasking" for spaces this small I can't really imagine why you
would bother :-) A simple round robin scheduler synchronised to a timer
interrupt is more than sufficient for me, throw in some interrupt handling
for the few peripherals of the chip you are using and you have pretty much
used up your 8K anyway :-)

My knowledge of compiler technology is approximately nil, I am somewhat
surprised (although I probably shouldn't be :-)) at what you say is required
to go into the runtime libraries as opposed to code generated by the
compiler i.e. exception handling is the only surprise from the list you have
mentioned.

Is run-time checking generated by a compiler for which you have a code
generator? or is that more runtime work? I guess even if the compiler
generated the runtime checking you need the exception handling to catch it
:-) Although (hopefully), a really simple exception handling mechanism could
be easily achieved (as opposed to a full traceback system - one of the
micros I have just finished using had an 8 deep hardware stack that was
inaccessible from software - no way to perform a traceback :-)). But in the
initial case just catching the exception would be start.....

Anyway, doesn't look like I can get anything "off the shelf" from gcc 3.X -
perhaps I should start browsing the gnat/gcc 3.X source to get some idea of
where and what needs modifications.

Thanks for the replies,
Peter


"Randy Brukardt" <randy@rrsoftware.com> wrote in message
news:vrih63aerng37f@corp.supernews.com...
> "Peter Milliken" <peterm@resmed.com.au> wrote in message
> news:zgRsb.200$co2.10332@nnrp1.ozemail.com.au...
> > Subject pretty much says it all.
> >
> > Now that you can build an Ada compiler using gcc 3.X (well, according to
> the
> > build instructions of gcc 3.x :-)), I began to wonder whether it was
> > possible to build a cross-compiler for an 8-bit target processor. The
> 8-bit
> > processor family in question is already supported by gcc (I believe).
> >
> > When I say "possible", I just mean "follow the cross-compiling
> instructions
> > and out pops an Ada compiler" - I don't mean, "spend months of work
> patching
> > various files and then you might have an Ada compiler" :-)
>
> To not answer your actual question at all, but...
>
> As someone else pointed out, the biggest cost/overhead is porting the
> runtime libraries. Speaking for Janus/Ada, porting the code
> generator/compiler usually only takes a month or so (and that's for
building
> a code generator from scratch). But building the basic runtime support for
> exceptions, tasking, floating point (which usually has to be emulated on
> small processors), etc. can take a lot of time. In addition, that support
> can make programs quite large.
>
> Because of this, I think you'd have trouble making acceptable programs
with
> a general-purpose compiler like GCC.
>
> Janus/Ada was originally built for Z-80 and 8086 processors without much
> memory. Thus, we only load floating point and tasking support when they
are
> used. That isn't very valuable on standard systems like Windows these
days,
> but it matters a lot on 8-bit systems.
>
> The only reason that we don't support 8-bit processors is a lack of
demand.
> Everyone seems to use a different processor, and thus we cannot really
> justify the investment building code generators (easy) and runtime
libraries
> (not as easy) for each one.
>
> Of course, we're always interested in customization projects, but that
won't
> help you convince your manager...
>
>                    Randy Brukardt
>
>
>
>
>

Re: Is it possible to build an Ada cross-compiler for an 8-bit embedded target now that gcc 3.X has support for Ada?

[Randy Brukardt]

"Peter Milliken" <peterm@resmed.com.au> wrote in message
news:cPuub.611$W07.11450@nnrp1.ozemail.com.au...
> In the initial case, I wouldn't be that interested in tasking or floating
> point support. I would like exception handling and run-time checking
though
> :-)
>
> My current application space is of the order of 8K so my "needs" are
fairly
> modest from the perspective of Ada features. Whilst I know people have
tiny
> OS's and "tasking" for spaces this small I can't really imagine why you
> would bother :-) A simple round robin scheduler synchronised to a timer
> interrupt is more than sufficient for me, throw in some interrupt handling
> for the few peripherals of the chip you are using and you have pretty much
> used up your 8K anyway :-)

Right. Which is why we went to the lengths of keeping the floating point and
tasking separate.

> My knowledge of compiler technology is approximately nil, I am somewhat
> surprised (although I probably shouldn't be :-)) at what you say is
required
> to go into the runtime libraries as opposed to code generated by the
> compiler i.e. exception handling is the only surprise from the list you
have
> mentioned.

Well, we probably have more use of the Janus/Ada runtime libraries than some
other compilers do. (We use the heap more extensively, for instance.) But
anything that takes more than a handful of instructions ends up in the
runtime. Even multiply and divide end up there on processors that don't
support those operations in the instruction set.

> Is run-time checking generated by a compiler for which you have a code
> generator? or is that more runtime work? I guess even if the compiler
> generated the runtime checking you need the exception handling to catch it
> :-) Although (hopefully), a really simple exception handling mechanism
could
> be easily achieved (as opposed to a full traceback system - one of the
> micros I have just finished using had an 8 deep hardware stack that was
> inaccessible from software - no way to perform a traceback :-)). But in
the
> initial case just catching the exception would be start.....

I can't speak for compilers in general (of course), but in Janus/Ada, the
checking itself is part of the generated code. If the check fails, then a
call is made to the runtime to raise the exception. Obviously, you could
live without exception handling, but you'd still need some sort of routine
to report the error (send the error string(s) to a debug port, say).

The traceback stuff in Janus/Ada doesn't take that much code, but if you're
trying to get your program into 8K, you'd probably be better off without it.

> Anyway, doesn't look like I can get anything "off the shelf" from gcc
3.X -
> perhaps I should start browsing the gnat/gcc 3.X source to get some idea
of
> where and what needs modifications.

Sounds like a plan. Good luck.

               Randy.