From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-91-241.ec2.internal X-Spam-Level: X-Spam-Status: No, score=0.0 required=3.0 tests=none autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Should light runtimes get more consideration? Date: Thu, 28 Sep 2023 14:25:18 +0100 Organization: A noiseless patient Spider Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain Injection-Info: dont-email.me; posting-host="f11e4b71224519ee7e9dc80c08b5d4c4"; logging-data="3896174"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/uy8zZM9J9SPqUmF6toZFSHC/dh72IZdI=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (darwin) Cancel-Lock: sha1:hEiHmp2tU5JxvH4ywTcLBOO4aQs= sha1:wk42jPARKIT4K2ICKGUA4mmkVfQ= Xref: news.eternal-september.org comp.lang.ada:65742 List-Id: Kevin Chadwick 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