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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.50.176.202 with SMTP id ck10mr9721563igc.5.1424979368596; Thu, 26 Feb 2015 11:36:08 -0800 (PST) X-Received: by 10.140.98.172 with SMTP id o41mr155568qge.34.1424979368445; Thu, 26 Feb 2015 11:36:08 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!hl2no32301754igb.0!news-out.google.com!c1ni201qar.1!nntp.google.com!j7no7798547qaq.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 26 Feb 2015 11:36:07 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=105.236.99.178; posting-account=orbgeAkAAADzWCTlruxuX_Ts4lIq8C5J NNTP-Posting-Host: 105.236.99.178 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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <8bde840e-4239-42f0-9a92-410b33163007@googlegroups.com> Subject: Re: silly ravenscar question From: jan.de.kruyf@gmail.com Injection-Date: Thu, 26 Feb 2015 19:36:08 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Received-Bytes: 5316 X-Received-Body-CRC: 3108657409 Xref: news.eternal-september.org comp.lang.ada:25047 Date: 2015-02-26T11:36:07-08:00 List-Id: On Thursday, February 26, 2015 at 4:57:13 PM UTC+2, Simon Wright wrote: > said elsewhere, what an odd place to find it!) indeed! Someone does not use doxygen. How unsettling. . . . Thanks for your long post. I will look throught it later. There is a lot to be learned still. Would it be unsettling if I asked why there is no system.ads in the zfp collection? especially the compiler switches at the end. Cheers, j. > > > 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!