Re: Ada, the best language with the not-so-best tool chain

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

On 12-10-10 08:56 , Stephen Leake wrote:
> kalvin.news@gmail.com writes:
> 
>> I agree with Niklas. Some bare metal system require that the (C
>> language) startup code does some initialisation for the runtime
>> system. 
> 
> I'm confused. If you are using someone else's "runtime system", then in
> what sense is this "baremetal"?

It was Ludovic who said that baremetal programming is hard in any
language, especially the bootstrap stage.

The bootstrap can indeed be complex. Some of the bigger, more complex
microcontrollers start up after reset in a kind of "safe mode" with
perhaps no usable SW stack, perhaps a very slow clock, and perhaps
unable to access off-chip memory. To enable normal operation, the clock
generator has to be configured, the off-chip memory controller has to be
configured, perhaps some parts of the app SW have to be copied from the
flash to RAM, etc.

The details of this processor configuration phase can be complex and
very different for different chips. For some chips, the bootstrap can
include setting up some standard interrupt/trap handlers, for example
register-file underflow and overflow handlers on SPARCs, that remain
active during app SW execution (unless the app SW deliberately
deactivates or modifies them).

And then the language-specific initialization has be done: initialize
statically allocated variables, set up a usable SW stack, elaborate Ada
library units, etc. The details depend on the language(s) and the
compiler(s), but not so much on the chip.

Finally, this bootstrap code jumps to main(), or its equivalent in Ada
app SW. And *then* the app SW is in full control of the processor - able
to access "bare metal" with no OS in between.

Processor development kits typically come with development environments
that handle the bootstrap automatically, for C programs and up to
entering main(). An Ada compiler could probably use the same bootstrap
and perform elaboration as the first step of main().

> It sounds like you are just talking about the choice of what OS to use;
> either a fully POSIX compliant one, or a small subset implemented by
> some hardware vendor.

Ludovic, Kelvin, and I were talking about the bootstrap, I believe. This
is not an OS, since it generally leaves the app SW in full control, and
does not try to manage or control further operation of the app SW.

For Ada, the situation is a little more complex, since the language
itself includes features (tasking) that, for other languages like C, are
usually provided by an OS. Should the code that implements Ada tasking
be seen as a language-specific library (like libc for C), or as an OS?

Are the standard C libraries like libc an OS or a "runtime"? You could
say they are a "runtime", since they come from the "system", and not
from the app developer, and they support the execution of the app SW at
runtime.

The difference is perhaps that the standard C libraries are pretty easy
to implement in a (mostly) portable way, while Ada tasking support is
more processor-dependent.

>> It is a shame, that we don't have Ada support for these bare metal
>> boards. If we could have an Ada compiler for popular microcontrollers
>> like ARM and MIPS (PIC32), Ada might get more popular as the hobbyist
>> engineers could play with Ada and see its strength, and dispel the
>> myths regarding Ada.
> 
> If you are willing to settle for the "C subset" of Ada, getting it
> running on a non-POSIX system is relatively straightforward. Usually
> what happens then is the users say "but Ada promised tasking, fixed
> point arithmetic, and exceptions!". That's why you need a real OS, not a
> small subset.

I doubt that fixed-point arithmetic and exceptions need a "real OS". If
a C system supports setjmp/longjmp, you do not call it an OS.
Implementing tasking is certainly easier if you can delegate to a "real
OS", but traditionally Ada compilers for embedded systems provide a
Run-Time System that implements tasking directly, without a real OS
underneath. Some of these RTS have been quite small; IIRC the RTS in TLD
Ada 83 for the MIL-STD-1750 processor was something like 8 KB.

> TANSTAAFL.

Indeed. But there are cheap lunches (snacks, really) and expensive
lunches. As a lunch, I seems to me that an Ada RTS is closer to the
"snack" level.

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