Re: Why so hard to come up with a simple embedded Ada system?

[Lucretia <Lucretia9000@yahoo.co.uk>]

On Jul 14, 5:55 am, use...@scriptoriumdesigns.com wrote:
> I'll just come out and say it - for a language that was designed for
> as much for embedded applications as for anything, it seems to be
> maddeningly difficult to actually get Ada on a modest embedded

I have to agree, sort of. I have some comments and some questions
regarding this :D

> platform.  By modest I mean low-end 32 bits, no MMU.  ARM7 or Cortex
> Mx would be my first choice.  I can be up and running on such a
> platform with C and a tasking library in a day (Rowley Crossworks,
> nice package).  Why can't I do the same with Ada?  Or rather, to avoid
> making this about me, why can't an embedded programmer - student,
> hobbyist or professional - who's heard about Ada and wants to give it
> a spin, including hard-realtime concurrency, just do it?
>
> If Ada fans (I include myself) want to see Ada get more exposure, this
> seems like not only a desirable step but a necessary one.  I can run C
> on a thousand such boards, and I can't (AFAIK) run Ada on one.
>
> Maybe this is all available, and I just haven't found out where.  Then
> that's a problem too, but I'll be happy to hear about it.
>
> All comments welcome.

With GCC, you can set up GCC, Binutils and Newlib/DietC/uClibc and
have a tasking environment on bare hardware - I've not tried it
myself, so cannot testify to the tasking side of things.

With GCC/GNAT you can do the same thing, but depending on hardware,
depends on what you get. By building for a target of <cpu>-elf, you
will get gnatbind and gnat1 (compiler), but you won't get an installed
runtime. See my site for more info on building these compilers (http://
archeia.com/an-ada95-hello-world-style-kernel.html).

At this point you would be where are with a C library (minus the
tasking and the large runtime). So, you would need to tinker with the
standard.ads package to configure the runtime that you are allowing
people to use, copying bits in from the GNAT source as and when GCC
asked for it. i.e. do you want the secondary stack available? Do you
want it dynamic or static? If so, you need the extra memory for it. Do
you want tasking? depending on the CPU, depends on whether the code is
there for it. Do you want tasking? See below for exceptions[*]. You'll
need to provide primitives that the runtime can use to implement it.
You can configure the runtime for what you want, but you have to
provide the underlying code to support it. Basic parts of the runtime
can be used though, quite easily.

For this kind of work, people just work with a compiler targeted for
the hardware (the target I mentioned above), but for Ada, should we be
creating our own --target=<target> so that we can build a runtime
within the normal GCC build system? Or should we be creating a port
specifically for the board, i.e. adding extra functionality into the
build system to support building for <cpu>-elf?

* On ARM, you can have SJLJ exception handling which isn't part of the
ARM ABI. For zero cost exceptions (part of the ABI), this needs to be
ported as the code just isn't there. I've looked into this recently
and I'm not stuck with the code, I'm stuck trying to work out how to
get a toolchain. I thought I'd try doing it on Maemo as I have an N900
available, but the SDK is based on Scratchbox and I'm on 64-bit and to
be honest, the SB people, point to the Maemo people and the Maemo
people don't give a shit, so don't help.

I think that made sense :D

Luke.