Should light runtimes get more consideration?

[Kevin Chadwick]

I created the issue below a little while ago. Today I wonder whether Ada
2022s 'Image attribute on records use of Unbounded strings is for good
reason. Is it an oversight that Bounded String would work with the new
light runtime or String with all runtimes including the older zero
footprint runtimes?

Perhaps it was decided that a light runtime would not use this feature? and
I can cerrainly avoid it. However I use a light runtime with 100s of
kilobytes or ram and many gigabytes of flash.

Ada is a much nicer language than Rust which uses unsafe all over for
embedded but one thing that is interesting is that I believe all Rust code
can be run easily on any target. Should Ada aspire to that?

On the other hand micros are becoming multiprocessor bringing more demand
for tasking (protected types are not compatible with a light runtime) but
personally I believe multi chip single core designs are far better than
multicore and not only due to the impossibility of side channel attacks
like spectre.

https://github.com/Ada-Rapporteur-Group/User-Community-Input/issues/67

--
Regards, Kc

[Randy Brukardt]

As noted on the ARG Github, you confused the Unbounded version of
Text_Buffers with an unbounded string (completely unrelated things), and
moreover, failed to notice that the language provides multiple ways to use a
Bounded Text_Buffer instead. So the language addresses this particular
concern.

I don't know if GNAT implements all of those ways (in particular, the
restriction Max_Image_Length), but that is hardly the fault of the language!

For anyone else interested in this particular discussion, I recommend
reading and following up on the ARG Githib issue rather than here
(https://github.com/Ada-Rapporteur-Group/User-Community-Input/issues/67).

Randy.


"Kevin Chadwick" <kc-u...@chadwicks.me.uk> wrote in message
news:ueug62$2fvor$1...@dont-email.me...

[Kevin Chadwick]

>Bounded Text_Buffer instead. So the language addresses this particular
>concern.
>
>I don't know if GNAT implements all of those ways (in particular, the
>restriction Max_Image_Length), but that is hardly the fault of the language!

I see. I guess the error message could suggest those options, too. Perhaps
after the 2022 Gnat support work is completed.

That buffer support is pretty neat but my main concern which Gnat may (it
may not) address more than the current language by providing a cortex
runtime. Is that such demanding runtimes are brilliant but I am not sure if
even Ravenscar is scalable to so many microchips such as Rust is trying to
support. That isn't a huge issue but barriers to entry like having to work
out your own exception replacement might be turning users away. Which is
unfortunate when Ada is the best language out there by a significant margin
for embedded development or frankly any protocol or hardware register use.

Of course others will rightly argue Ada is the best due to many of the more
complex runtime features but that doesn't help with the issue of ease of
adoption on an unsupported microchip that I have raised above.

[Simon Wright]

Kevin Chadwick <kc-u...@chadwicks.me.uk> writes:

> That buffer support is pretty neat but my main concern which Gnat may
> (it may not) address more than the current language by providing a
> cortex runtime. Is that such demanding runtimes are brilliant but I am
> not sure if even Ravenscar is scalable to so many microchips such as
> Rust is trying to support. That isn't a huge issue but barriers to
> entry like having to work out your own exception replacement might be
> turning users away. Which is unfortunate when Ada is the best language
> out there by a significant margin for embedded development or frankly
> any protocol or hardware register use.

When I started on Cortex GNAT RTS[1], a large part of the motivation
(aside from the fun element) was that AdaCore's bare-board RTSs were
GPL'd (they still are). Not that I cared about that, but other people
did.

I took the approach of AdaCore's SFP (small footprint) profile, now
renamed to light tasking, which implemented Ravenscar tasking but not
exception propagation or finalization.

The tasking part wasn't too hard, though I think exception handling and
finalization might have made things more difficult. Basing the tasking
on FreeRTOS saved a lot of grief (there are a couple of areas when the
resulting semantic isn't _quite_ Ada's).

I did some work on finalization, not merged.

Exception handling, without finalization, seemed a daunting prospect,
specially since the last project I worked on before retirement regarded
an unhandled exception as requiring a reboot (and ditching any missiles
in flight).

The current implementation has about 17 files (1 .h, 1 .s, 9 .ads, 4
.adb) to customise to the chip (setting up interrupt vectors, the clock,
and memory). There are about 200 Ada sources that are common.

AdaCore currently have 68 RTS packages in the Alire gnat_arm_elf
toolchain. 18 of these are 'embedded' packages (full Ada, but with
Jorvik tasking). I'd be surprised if they had a higher proportion of
chip dependency than my efforts. Most if not all of the exception
handling will be chip-independent. I'm not sure how many of the 90 or so
Ada sources in the STM32F4 gnarl/ directory are actually chip-dependent,
I get the impression it's not high.

--------------------

So, unless you're going to use some target that AdaCore haven't released
support for, your best bet must be to either use or at worst start from
the available RTS packages.

[1] https://github.com/simonjwright/cortex-gnat-rts

[DrPi]

> The current implementation has about 17 files (1 .h, 1 .s, 9 .ads, 4
> .adb) to customise to the chip (setting up interrupt vectors, the clock,
> and memory). There are about 200 Ada sources that are common.
>
> AdaCore currently have 68 RTS packages in the Alire gnat_arm_elf
> toolchain. 18 of these are 'embedded' packages (full Ada, but with
> Jorvik tasking). I'd be surprised if they had a higher proportion of
> chip dependency than my efforts. Most if not all of the exception
> handling will be chip-independent. I'm not sure how many of the 90 or so
> Ada sources in the STM32F4 gnarl/ directory are actually chip-dependent,
> I get the impression it's not high.
>

Right, not high.

I've created 2 of them based on one of the Adacore RTS.
I can't say it has been easy since you first have to understand how it
works (and things change at each new release).
One important point is that some critical parameters are hard coded in
the source code. Like the core frequency. You MUST use a fix clock
frequency to get correct time management (delays, ...). This is why in
their last version, you run a script to generate part of the RTS source
code (frequency and other parameters are injected in the source code).
When you change the core frequency you have to regenerate the RTS binary.

I created the RTS to evaluate the potential use of Ada on embedded
targets. I have never used them except for testing.
The main reason is that Adacore RTS are made for specific use (avionics,
spatial...). The code using these RTS must be provable (or as provable
as possible). This induce big limitations.
Tasking is very limited. For example you can't use timeouts. Never. They
propose a workaround but it is complex and not equivalent to a real
timeout management.
I'd like to have a full Ada RTS for embedded targets, like on desktop. I
don't need to certify/prove my hardware/software.
Some people say micro-controllers are too limited for this. That's true
for some of them. I use micro-controllers with megabytes FLASH memory
and hundreds kilobytes of RAM. Is this not enough ?

[Simon Wright]

DrPi <3...@drpi.fr> writes:

> Tasking is very limited. For example you can't use
> timeouts. Never. They propose a workaround but it is complex and not
> equivalent to a real timeout management.

Not sure what a "real timeout management" would look like?

> I'd like to have a full Ada RTS for embedded targets, like on
> desktop.

Have you considered using something like a Raspberry Pi?

[DrPi]

A RaspberryPi is a computer (based on a microprocessor with an OS), not
an micro-controller. It consumes a lot of electrical power. The OS
(linux) is not real time. It uses a lot of board space. The processor is
a proprietary black box...

[Chris Townley]

Plenty use the Raspberry Pi as a microcontroller

--
Chris

[Kevin Chadwick]

>>>> Tasking is very limited. For example you can't use
>>>> timeouts. Never. They propose a workaround but it is complex and not
>>>> equivalent to a real timeout management.
>>>
>>> Not sure what a "real timeout management" would look like?
>>>
>>>> I'd like to have a full Ada RTS for embedded targets, like on
>>>> desktop.
>>>
>>> Have you considered using something like a Raspberry Pi?
>> A RaspberryPi is a computer (based on a microprocessor with an OS), not
>> an micro-controller. It consumes a lot of electrical power. The OS
>> (linux) is not real time. It uses a lot of board space. The processor is
>> a proprietary black box...
>>
>
>Plenty use the Raspberry Pi as a microcontroller

I think Simons point was that Arm/Linux has a working full runtime. I guess
bare raspberry pie would not and I guess it would be a rather large module
or board or single board computer depending on the model.

WRT energy use. I use a low power run feature on the STM32L4 which means the
system clock speed can change at any time. That seems to be incompatible
with any runtime that I have seen except the minimal light-cortex-m4 one. I
assume working with clocks is more scalable than working with runtimes but
I do not know for sure.

--
Regards, Kc

[Chris Townley]

Agreed, but in addition to the mainline Pis there is the zero, and the
pico, which has a 'RP2040' made by Raspberry Pi and is a dual-core ARM
Cortex M0+ processor, with a flexible clock running up to 133MHz

--
Chris

[DrPi]

> WRT energy use. I use a low power run feature on the STM32L4 which means
> the
> system clock speed can change at any time. That seems to be incompatible
> with any runtime that I have seen except the minimal light-cortex-m4 one. I
> assume working with clocks is more scalable than working with runtimes but
> I do not know for sure.
>

The fact that the clock speed is hard coded is a design choice.
It simplifies the time management.
It makes the runtime more "hard real time" compliant since there are
less computations to be done at execution.

[DrPi]

A runtime for the RP2040 already exist. It is based on the Adacore ARM
runtimes so has the same limitations.