Re: Ada platforms and pricing, was: Re: a new language, designed for safety !

["Randy Brukardt" <randy@rrsoftware.com>]

"Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
message news:lnsqus$d4j$1@dont-email.me...
> On 2014-06-17, Randy Brukardt <randy@rrsoftware.com> wrote:
>> "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in
>> message news:lnn8ff$k42$1@dont-email.me...
>>> Many of those people wanting to explore the language will be wanting
>>> to explore Ada by using it on embedded platforms so you need a range
>>> of Ada cross compilers available in the same way you have a range of
>>> C cross compilers available for those same people to use.
>>
>> It's impractical to have any such cross-compilers. Every such compiler
>> (run-time, really) has to be tailored to the specific board in question. 
>> We
>> treated each embedded compiler as something that would require extensive
>> support, and I still think we lost money on each.
>>
>
> You are thinking of this as a monolithic commercial product. Things are
> much more modular in the open source world.

Not at all. Janus/Ada is structured almost as you describe below:

> Taking the ARM bare metal (C language) world as an example:
>
> 1) At the bottom layer you have the compiler itself. This just generates
> code for a set of ARM architecture variants such as Cortex-M3 and
> Cortex-A8 as well as older ARM architecture variants such as the ARMv5
> variants. It has absolutely no knowledge of any specific MCU or any
> board which that MCU might be placed on. Things like memory layouts
> are handled in linker scripts.

Yup. But no one can do anything useful with such a thing. It's trivial to 
take a version of Janus/Ada and use it as a cross-compiler for some board. 
But without a runtime, hardware support, and the like, only the most 
dedicated people could use it for anything.

> 2) At the next layer up you have code to support a specific MCU. As
> well as MCU specific startup code, this includes things like interrupt
> handling which is MCU specific in the ARM world. This code generally
> comes from the manufacturer of the MCU and is usually free.

But it's probably not in a form that could be used for Ada. Certainly not 
unless you're planning to require having an C compiler around as well (not 
really good marketing for Ada).

> 3) At the next layer up you have a code library to support the
> peripherals on a specific board. If this is a standard board, this
> code might be written for you by the manufacturer, or you might have
> to write this code yourself.

Right, and this is where the problem is. These have to developed for every 
board for Ada, and there's little likelyhood of anything from the 
manufacturer.

You could of course use some zero-footprint subset of Ada to minimize the 
need for that; to me, such things are so emasculated (no exceptions, no 
tasks, no I/O, etc.) that they're of little value for teaching Ada. (You get 
C-in-Ada-syntax at best, little to be gained there.)

...
> I don't know about Luke, but when I talk about Ada cross compilers,
> I'm only really thinking about the first part (the compiler itself)
> although you will probably need to add in Ada specific initialisation
> code into the MCU startup code. Provided the calls into the Ada RTL
> are cleanly documented then that's not a problem for me.

You'd be very much in the minority. Remember, for the sorts of people you 
are talking about, the compiler is going to have to work pretty much out of 
the box, as the normal person isn't going to have the Ada knowledge needed 
to write a runtime for a particular board.

Besides, pretty much any compiler will work fine as a bare targeted 
compiler; the problems are all in the libraries. (The only reason you 
couldn't use Janus/Ada for that would be the fact that we never built an ARM 
code generator. But that's easy to do, especially if you're not insisting on 
perfect code -- less than a months work. The RTS would take 3 times that.)

                         Randy.