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

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 14-06-23 02:38 , Randy Brukardt wrote:
> "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.

 [snip]

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

While I would like to have the standard Ada tasking, timing, and
exception support, I would most definitely prefer an Ada subset without
them, over C. As I remember, prof. McCormick's experience from the
model-railway exercise (where his students failed when they used C, but
succeeded with Ada) identified Ada's advantage over C to be in the
better scalar typing, not in the features that require a full RTL (but I
don't remember if exceptions were a factor in McCormick's experience).

I am currently working on an Ada project with a null run-time and a
proprietary small multi-threading kernel. But I still feel I am "doing
Ada", although with a different syntax for tasking. All the advantages
of the type and package system are still there, and they are, to me, the
main feature of Ada (in this application domain, at least).

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .