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: longest path through a task
Date: Thu, 28 May 2015 18:52:54 +0100
Organization: A noiseless patient Spider
Message-ID: <lypp5ka8sp.fsf@pushface.org>
References: <9ad1fcdc-cdf9-4ff0-aa7e-051d53b6736a@googlegroups.com>
	<csmmjfFg5hU1@mid.individual.net>
	<7d56e720-5e91-4950-b4ae-29d7ddbdc11a@googlegroups.com>
	<lymw0o1wvt.fsf@pushface.org>
	<2e388144-8941-41a6-a8aa-447a798006d8@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: mx02.eternal-september.org;
 posting-host="8f3bdf433f184ad9fec01bd73e350c65";
	logging-data="27396"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1+eNpzj7TR3sNCSvI/t4u0pMkZdH8jJ0Go="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin)
Cancel-Lock: sha1:kPWOZk3VvlAMBo0kqSIVj2XNDhU=
	sha1:RhTD+vArdCmUuFzMrAnlZZAcPQk=
Xref: news.eternal-september.org comp.lang.ada:26036
Date: 2015-05-28T18:52:54+01:00
List-Id: <comp.lang.ada>

jan.de.kruyf@gmail.com writes:

> On Thursday, May 28, 2015 at 6:37:28 PM UTC+2, Simon Wright wrote:
>
>> 
>> > I dumped the multithread stuff and made a single-thread / multitask
>> > runtime (slow in Ada unfortunately, but not as slow as multi-threading
>> > and interrupts. The Ravenscar runtime tries to be everything for
>> > everybody).
>> 
>> Just did some measurements (clumsily) using the Cortex-M4 counter as in
>> [1], and from entering the Ada handler to the triggered task starting to
>> execute averaged at 1200 cycles (6.7 us) with -Og, 1070 cycles (5.9 us)
>> with -O2. There is some code in the C handler to redirect to the Ada
>> handler: see [2], starting at line 236.
>> 
>> I wrote the C handling using weak symbols, so there's no reason (that I
>> can see) why an interrupt that needed better performance shouldn't hook
>> in directly, avoiding the Ada RTS; not so obvious how it would then
>> communicate with the rest of the code.
>> 
>> [1] http://stackoverflow.com/a/19124472
>> [2]
>> https://sourceforge.net/p/stm32f4-gnat-rts/code/ci/default/tree/stm32f429i-disco-rtos/src/stm32f4xx_it.c
>
> I lost you a bit here Simon, your thinking is way ahead of your
> fingers :) I guess. or I am not familiar with your terminology. (more
> than likely)

I have been accused of terseness, sorry

> Is this interrupt latency? or software interrupt latency? 
> Are you running multi threaded? are you triggering a task in this
> thread to run in that thread?
> Is this including your C runtime?

This is a Ravenscar runtime; the C interrupt handler has to invoke the
Ada handler, which was registered by the Ada runtime when it saw a PO
like

   protected Button
   with
     Interrupt_Priority => System.Interrupt_Priority'First
   is
      entry Wait_For_Trigger;
   private
      Triggered : Boolean := False;
      procedure Handler;
      pragma Attach_Handler (Handler, Ada.Interrupts.Names.EXTI0_IRQ);
   end Button;

and I started timing in Button.Handler.

The corresponding task called Button.Wait_For_Trigger and I ended timing
immediately on return.