I expect the first four (esp. the first two) will swing it toward optimizing the abstraction towards facilitating TASK and other high-level constructs (protected objects, parallel, etc). #5 (Forth) is very good at being small and very low-level, with very quick abstracting due to how ‘Words’ (read subprograms) are defined as “(1) a list of words to execute; or (2) a [typically very small] chunk of machine-code to execute.” Using DIANA-2022 may help guide the architecture as well, though this might be a bit too much to ‘feed’ it.
One thing that may be very helpful is to ‘remind’ the AI how portable Ada is: when Charlie5 and I were doing the refresh, I found an old (30ish years old) implementation that had been distributed in one of the Walnut Creek archive CDs. In order to get it to a compliable (by GNAT) state, I had only to split a few files (GNAT has an implementation limitation, unable to have multiple compilation units in a single file) and rename a few identifiers that had become reserved words… I think that program was written on a completely different architecture+OS+compiler. — This is to say, instead of preferring to make the system cater to the details (as C does), make the system cater to the problem-space (inasmuch as possible).
I suggest to evaluate orthogonal idea related to runtimes/boards - create runtimes (may be only tasking part) on the fly for particular project, using description file, like you suggest for device mapping.
There is no need to provide a lot of runtime crates, just, for example, crate for core features for CPU platform (Cortex-M3, Cortex-M4, etc), memory utilities crate (implementation of memset/etc when necessary, generic startup code for MCU or MCU family, tasking support library (out of runtime), tasking support utilities for CPU architecture, etc. Project will provide descriptor file for tool which consolidates all information, generates necessary packages for startup code, tasking parameters, peripheral configuration code, linker script.
My attempt to do something like this can be found here
Real use case is ESP-IDF integration template
Startup code (for example, for STM32F412) is generated by instantiation of generic subprogram
using MCU binding descriptor
and information provided by the application project like this one
Tasking is of course in scope, but only as an option. If a user decides to build against ZPF or light runtime, that’s a deliberate decision for minimum overhead. Therefore layer 3 is currently split into optimized capabilities depending on the runtime.
That should be indeed possible. Most probably by just using alire with the right split of crates. On the other hand, Ada Machine currently has no specific need for changed runtimes besides the suggestion for a more generic Ada.TextIO for embedded. My fear is that supporting runtimes that deviate too much from what AdaCore does for GNAT might be a lot of effort. As you said, it’s orthogonal.