Re: STM32F4 GNAT Run Time System - roadmap

[jan.de.kruyf@gmail.com]

On Tuesday, June 9, 2015 at 2:02:25 PM UTC+2, Simon Wright wrote:
> Looking for some input on priorities for work.
> 
> * Standard library packages.
> * Other MCUs.
> * Finalization.
> * ?
> 
> Standard library packages
> -------------------------
> 
> An obvious omission is the rest of the Ada.Containers.Bounded* packages:
>   Doubly_Linked_Lists
>   Ordered_Maps
>   Hashed_Sets
>   Ordered_Sets
>   Multiway_Trees
>   Synchronized_Queues
>   Priority_Queues
> 
> Any other nice-to-haves? (I haven't looked at Annex G, might be
> problematic!)
> 
> Other MCUs
> ----------
> 
> STM have just released a significant number of affordable Nucleo
> development kits. The NUCLEO-F091RC has 48 MHz Cortex-M0 core, 256-KB
> Flash, 32-KB SRAM, which would just-about take my current testbed
> program; for the princely sum of UKP7.94 + p&p, 88 in stock in UK for
> next day delivery from Farnell[0].
> 
> The problem with this is that different MCUs require different compiler
> options, and building GCC for ARM with multilibs is only supported in
> the ARM fork at [1]; so far there are only GCC 4.9-based releases. GCC
> 4.9 is a perfectly competent compiler, of course.
> 
> Finalization
> ------------
> 
> It would be very nice to be able to use the generalized container
> iterators of Ada 2012 (generalized array iterators are already OK).
> 
> They require finalization: I've implemented finalization and generalized
> iteration over Bounded_Vectors in the 'finalization' branch at [2].
> 
> Unfortunately, adding finalization to a restricted runtime triggers bugs
> in GCC.
> 
> I've raised two GCC PRs; "gnatbind generates invalid code when
> finalization is enabled in restricted runtime"[3], and "Front-end error
> if exception propagation disabled"[4].
> 
> =====================================================================
> [0] http://uk.farnell.com/stm32-mcu-nucleo-board-flexible-prototyping
> [1] https://launchpad.net/gcc-arm-embedded
> [2]
> https://sourceforge.net/p/stm32f4-gnat-rts/code/ci/finalization/tree/
> [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66205
> [4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66242

Simon,
Thanks for all your hard work :)
on the matter of bug 66205:
-------
        if not Suppress_Standard_Library_On_Target then
            WBI ("   Is_Elaborated : Boolean := False;");
         end if;
-------
This ties with the behaviour I get on 4.7.4 
When Standard_Library is not suppressed it wants to load some Handler and initialize a handful of variables. So for mixed language mode with minimal runtime and a foreign linker I have to suppress the standard library, so 'adainit' purely does the elaboration of the stuff I wrote (be it program or runtime) 
As I said: with it, adainit does a few things more.

At the moment I am in the middle of a hairy issue in s-memory (getting an address overlay to work, so I ask for a few pages from the kernel and use it as a system byte array) But as soon as I have a working compile again, without errors, some time tomorrow, I will post the relevant code pieces with and without 'Suppress_Standard_Library_On_Target'. I think your binder gives out too much code from what I see.

the other bug ties in with my observations about exceptions on 4.7.4. Perhaps in a slightly different way. But I am not following your test case too well, its evening. 

As far as the road ahead:
The things you mentioned are certainly all 'nice to haves' but at the same time I personally have not missed them yet. Since it is easy enough to roll your own if and when the need arises. In a big project I would say that the priorities are quite different. There you look for lots of reusable software. But then I might be mistaken.

I would certainly vote for more cpu's that are usable 'off the shelf' with either a ravenscar profile or a zfp. But.
This has to go together with some kind of a publicity effort, otherwise it is just a nice hobby but it serves no real purpose. 

Maybe we need to ask David about his opinion.

Besides I like to mention that the big issue with micro controllers is a good, solid, workable hardware definition. You have chosen to go the 'cube' library route, which is viable of course. and it has the added advantage of having the hidden fix-ups packaged already. (And there are some, I discovered to my horror).
Personally I like to work on the bare metal though. However, I miss sorely some good hardware definition files. For the 407 I made them up as I went, but it is only a first try. The method needs to be discussed and perhaps improved upon. We have all this beautiful type machinery in Ada, so why not use it. 
Again, we need forum discussion and afterwards publicity! Otherwise it is all rather useless.

 I suppose I have talked enough again for tonight ,

cheers,

j.