Re: longest path through a task

[jan.de.kruyf@gmail.com]

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) 
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?
Sorry to be so inquisitive, but I like to understand even though I have a pea brain.

In the mean time I am having fun digesting Bruce's books' algorithms and trying to see how to apply them. I will have to go back to the Corti thesis I think, but it will not be as easy as what he did, since he could hack the compiler with relative ease (a one floppy compiler). I will probably end up entering code twice, in some reduced form to extract the longest path.

Thanks for your guys help.

j.