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

[Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>]

On 2014-06-22, Randy Brukardt <randy@rrsoftware.com> wrote:
> "Simon Clubley" <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote in 
> message news:lo7c2h$ura$1@dont-email.me...
>>
>> 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.
>

In the ARM world, that's more of a MCU specific issue instead of a board
specific issue. What could be done is to split the Ada RTL into cleanly
separated generic and hardware specific parts and provide a clean detailed
specification for implementing the hardware specific part.

> 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.
>

Some board specific configuration issues which might matter could be
things like memory layout which can be handled with linker scripts.

>> 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.
>

Sorry, I wasn't clear above.

What I meant was that Text_IO (or something like it) would be
implemented, but at the lowest level, the Text_IO package would just
call a user supplied routine to actually output the character(s) to the
hardware and that user supplied routine would not care about, or even
know anything about, the structure of the Ada RTL package calling it.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world