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:lo7c2h$ura$1@dont-email.me...
> On 2014-06-18, Randy Brukardt <randy@rrsoftware.com> wrote:
>> "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:
>>>>
>>>> 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.
>>>>
...
>>> 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.
>>
>
> To me, I mentally split the problem into two categories: The support
> for Ada language functionality and the support for peripherals on the
> specific board. I regard only the first part as really a part of the
> actual compiler, but it is a required part.
>
> However, my feeling is that the Ada RTL support, once implemented, is
> pretty generic within a MCU architecture and is not really board
> specific.

That's not my experience. Remember that "basic Ada support" includes things 
like timers (Ada.Real_Time, delay statements), some method of handling 
exceptions (which generally means supporting hardware traps), and usually 
tasking (which means some method of context switching).

All of these require interrupt support on bare boards, and that never seems 
to be quite the same from board to board.

There's certainly a shared part, but the configurations are different for 
each board. And you have to be pretty familar with the boards in order to do 
those; your average tinkerer isn't likely to be able to do that.

> You may need some configuration and interface options for things like
> I/O operations, with calls to user supplied I/O packages. These packages
> would only concern themselves with the lowest level, interfacing to
> the hardware itself and not provide any generic Ada RTL support.
>
> In these user supplied packages, I'm thinking about things like an Ada
> version of, say, putchar() which would just output the passed character
> to some hardware device without concerning itself about anything other
> than that.

Fair enough. I found back in the day that you had to be able to connect that 
with Text_IO for useful output (for instance, the crash messages from the 
Janus/Ada runtime). But that's clearly a secondary need. I wasn't thinking 
about full I/O support, for instance, since it usually doesn't make sense in 
that environment.

>>> 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).
>>
>
> There is some C code at the very lowest level of GNAT.

Sure, but it's compiled; you don't need a C compiler in order to be able to 
use GNAT. If you require people to use C code in their setup, they'll need 
to get the C compiler working first. At that point, most people will wonder 
why they're spending time to get Ada working rather than working on their 
project (the fun part, hopefully).

...
> I don't really see the support for the peripherals as part of the
> compiler as such. For example, the various MCU and board manufacturers
> may provide their own bare metal support package for a board and all
> you need to do is download it from their website and build it with your
> own C compiler; it's not expected to be a part of gcc.

I'm not talking about "peripherals"; I'm talking about timers and trap 
handlers (for overflow, divide-by-zero, etc.) and the like. These things are 
required for a useful subset of Ada. (No clock and no exceptions means 
you're no longer really doing Ada, just Ada syntax.) I/O is optional, but 
not these other things.

                                  Randy.