Should light runtimes get more consideration?

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

Re: Should light runtimes get more consideration?

[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-usenet@chadwicks.me.uk> wrote in message 
news:ueug62$2fvor$1@dont-email.me...
>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 

Re: Should light runtimes get more consideration?

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

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

Re: Should light runtimes get more consideration?

[Simon Wright]

Kevin Chadwick <kc-usenet@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

Re: Should light runtimes get more consideration?

[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 ?

Re: Should light runtimes get more consideration?

[Simon Wright]

DrPi <314@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?

Re: Should light runtimes get more consideration?

[DrPi]

Le 28/09/2023 à 22:53, Simon Wright a écrit :
> DrPi <314@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?
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...

Re: Should light runtimes get more consideration?

[Chris Townley]

On 28/09/2023 22:18, DrPi wrote:
> Le 28/09/2023 à 22:53, Simon Wright a écrit :
>> DrPi <314@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?
> 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

-- 
Chris

Re: Should light runtimes get more consideration?

[Kevin Chadwick]

\r>>>> 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

Re: Should light runtimes get more consideration?

[Chris Townley]

On 29/09/2023 10:59, Kevin Chadwick wrote:
> 
>>>>> 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.
> 

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

Re: Should light runtimes get more consideration?

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

Re: Should light runtimes get more consideration?

[DrPi]

Le 29/09/2023 à 12:42, Chris Townley a écrit :
> On 29/09/2023 10:59, Kevin Chadwick wrote:
>>
>>>>>> 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.
>>
> 
> 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
> 
A runtime for the RP2040 already exist. It is based on the Adacore ARM 
runtimes so has the same limitations.