From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: silly ravenscar question
Date: Thu, 26 Feb 2015 14:57:10 +0000
Organization: A noiseless patient Spider
Message-ID: <lyoaog3em1.fsf@pushface.org>
References: <8e30f54c-81c4-4861-897c-bb6c563c76e8@googlegroups.com>
	<87wq37d12w.fsf@adaheads.sparre-andersen.dk>
	<7ae5ec06-f5e3-4c5f-ac95-58b4bf1256a0@googlegroups.com>
	<87egpfzapq.fsf@theworld.com>
	<99705630-02e3-4e43-9307-83e55336bc15@googlegroups.com>
	<lysidt3mp3.fsf@pushface.org>
	<fcafdbca-be65-41ab-a437-7b616cbc1279@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org;
 posting-host="342d0b904178f3fa79dba1c9d29f7c6c";
	logging-data="26240"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/EOpLH7/WDMXNCnXV1FpX0eciDpszJ8rM="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (darwin)
Cancel-Lock: sha1:SFcKiukU0ecC5QFp7RlN2JP7hbg=
	sha1:Ng6OwrGyzcT/ikrYDFFANQTPi3Q=
Xref: news.eternal-september.org comp.lang.ada:25045
Date: 2015-02-26T14:57:10+00:00
List-Id: <comp.lang.ada>

jan.de.kruyf@gmail.com writes:

> On Wednesday, February 25, 2015 at 7:50:17 PM UTC+2, Simon Wright wrote:

> Was it you that had read the Gnat spec for the STM34 x-compiler? About
> memory allocation and that? cause I did not find it.

In the gnat-gpl-2014-arm-elf-linux-bin.tar.gz look at
lib/gnat/arm-eabi/ravenscar-sfp-stm32f4/adainclude/s-memory.ads (as I've
said elsewhere, what an odd place to find it!)

> I had a first look at the zfp package. Do you know what would be
> missing in the language there?

My equivalent has

   pragma Restrictions (No_Allocators);
   pragma Restrictions (No_Delay);
   pragma Restrictions (No_Dispatch);
   pragma Restrictions (No_Enumeration_Maps);
   pragma Restrictions (No_Exception_Propagation);
   pragma Restrictions (No_Finalization);
   pragma Restrictions (No_Implicit_Dynamic_Code);
   pragma Restrictions (No_Protected_Types);
   pragma Restrictions (No_Recursion);
   pragma Restrictions (No_Secondary_Stack);
   pragma Restrictions (No_Tasking);

> Because the interrupt latencies in the Ravenscar implementation are
> NOT pleasant. Adacore has long and involved things before we get to
> the handler.

My version has the Cortex handler registered as an invocation of my
dummy_handler macro:

   /* Pointer to the interrupt handler wrapper created by Ada; the
      'object' is the actual PO. */
   typedef void (*handler_wrapper)(void *object);

   /* Array, to be indexed from Ada as Interrupt_ID (0 .. 90), of handler
      wrappers. The index values also match IRQn_Type, in
      $CUBE/Drivers/CMSIS/Device/ST/STM32F4xx/Include/stm32f429xx.h.

      Called from the weak IRQ handlers defined below if not null.

      The Ada side will register handlers here; see
      System.Interupts.Install_Restricted_Handlers. */
   handler_wrapper _gnat_interrupt_handlers[91] = {0, };

   /* Parallel array containing the actual parameter to be passed to the
      handler wrapper.

      Implemented as parallel arrays rather than array of structs to be
      sure that interrupt_handlers[] is initialized. */
   void * _gnat_interrupt_handler_parameters[91] = {0, };

   #define dummy_handler(name, offset)                     \
   __attribute__((weak)) void name()                       \
   {                                                       \
     if (_gnat_interrupt_handlers[offset]) {               \
       _gnat_interrupt_handlers[offset]                    \
         (_gnat_interrupt_handler_parameters[offset]);     \
     } else {                                              \
       while (1) {};                                       \
     }                                                     \
   }

and the Ada handler (as reported by -gnatdg, and the same as for the
AdaCore RTS) is

   procedure buttons__button__handlerP (_object : in out
     buttons__buttonTV) is
   begin
      %push_constraint_error_label ()
      %push_program_error_label ()
      %push_storage_error_label ()
      $system__tasking__protected_objects__single_entry__lock_entry (
        _object._object'unchecked_access);
      buttons__button__handlerN (_object);
      $system__tasking__protected_objects__single_entry__service_entry
        (_object._object'unchecked_access);
      %pop_constraint_error_label
      %pop_program_error_label
      %pop_storage_error_label
      return;
   end buttons__button__handlerP;

I don't know how the % lines translate to code; for me, the Lock_Entry
call will find that we're in an ISR and do nothing; the HandlerN is the
code you wrote; and Service_Entry will check to see whether (the) entry
has been released and execute its code as well if so.

HTH!