* Should light runtimes get more consideration? @ 2023-09-26 11:44 Kevin Chadwick 2023-09-28 3:48 ` Randy Brukardt 0 siblings, 1 reply; 12+ messages in thread From: Kevin Chadwick @ 2023-09-26 11:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Should light runtimes get more consideration? 2023-09-26 11:44 Should light runtimes get more consideration? Kevin Chadwick @ 2023-09-28 3:48 ` Randy Brukardt 2023-09-28 9:46 ` Kevin Chadwick 0 siblings, 1 reply; 12+ messages in thread From: Randy Brukardt @ 2023-09-28 3:48 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Should light runtimes get more consideration? 2023-09-28 3:48 ` Randy Brukardt @ 2023-09-28 9:46 ` Kevin Chadwick 2023-09-28 13:25 ` Simon Wright 0 siblings, 1 reply; 12+ messages in thread From: Kevin Chadwick @ 2023-09-28 9:46 UTC (permalink / raw) >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). > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Should light runtimes get more consideration? 2023-09-28 9:46 ` Kevin Chadwick @ 2023-09-28 13:25 ` Simon Wright 2023-09-28 17:51 ` DrPi 0 siblings, 1 reply; 12+ messages in thread From: Simon Wright @ 2023-09-28 13:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Should light runtimes get more consideration? 2023-09-28 13:25 ` Simon Wright @ 2023-09-28 17:51 ` DrPi 2023-09-28 20:53 ` Simon Wright 0 siblings, 1 reply; 12+ messages in thread From: DrPi @ 2023-09-28 17:51 UTC (permalink / raw) > 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 ? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Should light runtimes get more consideration? 2023-09-28 17:51 ` DrPi @ 2023-09-28 20:53 ` Simon Wright 2023-09-28 21:18 ` DrPi 0 siblings, 1 reply; 12+ messages in thread From: Simon Wright @ 2023-09-28 20:53 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Should light runtimes get more consideration? 2023-09-28 20:53 ` Simon Wright @ 2023-09-28 21:18 ` DrPi 2023-09-28 23:51 ` Chris Townley 0 siblings, 1 reply; 12+ messages in thread From: DrPi @ 2023-09-28 21:18 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Should light runtimes get more consideration? 2023-09-28 21:18 ` DrPi @ 2023-09-28 23:51 ` Chris Townley 2023-09-29 9:59 ` Kevin Chadwick 0 siblings, 1 reply; 12+ messages in thread From: Chris Townley @ 2023-09-28 23:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Should light runtimes get more consideration? 2023-09-28 23:51 ` Chris Townley @ 2023-09-29 9:59 ` Kevin Chadwick 2023-09-29 10:42 ` Chris Townley 2023-09-29 13:42 ` DrPi 0 siblings, 2 replies; 12+ messages in thread From: Kevin Chadwick @ 2023-09-29 9:59 UTC (permalink / raw) \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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Should light runtimes get more consideration? 2023-09-29 9:59 ` Kevin Chadwick @ 2023-09-29 10:42 ` Chris Townley 2023-09-29 13:44 ` DrPi 2023-09-29 13:42 ` DrPi 1 sibling, 1 reply; 12+ messages in thread From: Chris Townley @ 2023-09-29 10:42 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Should light runtimes get more consideration? 2023-09-29 10:42 ` Chris Townley @ 2023-09-29 13:44 ` DrPi 0 siblings, 0 replies; 12+ messages in thread From: DrPi @ 2023-09-29 13:44 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Should light runtimes get more consideration? 2023-09-29 9:59 ` Kevin Chadwick 2023-09-29 10:42 ` Chris Townley @ 2023-09-29 13:42 ` DrPi 1 sibling, 0 replies; 12+ messages in thread From: DrPi @ 2023-09-29 13:42 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-09-29 13:44 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-09-26 11:44 Should light runtimes get more consideration? Kevin Chadwick 2023-09-28 3:48 ` Randy Brukardt 2023-09-28 9:46 ` Kevin Chadwick 2023-09-28 13:25 ` Simon Wright 2023-09-28 17:51 ` DrPi 2023-09-28 20:53 ` Simon Wright 2023-09-28 21:18 ` DrPi 2023-09-28 23:51 ` Chris Townley 2023-09-29 9:59 ` Kevin Chadwick 2023-09-29 10:42 ` Chris Townley 2023-09-29 13:44 ` DrPi 2023-09-29 13:42 ` DrPi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox