|Re: [hatari-devel] Code execution discontinuities and detecting them?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On maanantai 25 helmikuu 2013, Douglas Little wrote:
> I think it should be possible to filter out interrupt enter/exit events
> appearing like normal program flow changes / calls in a reliable way - if
> some of the CPU context is made available in the profiling data (either
> the status register or some housekeeping info belonging to UAE).
> You can try to identify via the last instruction, but you could perhaps
> get unlucky and have an interrupt occur in the wrong place, causing a
> bogus link in your callgraph. This seems like a very rare occurrence but
> when you're dealing with capture over many seconds, even rare things
> happen frequently enough to contribute confusion (some of this can even
> be seen in the last DOT example)
Does DSP have also this kind of interrupts?
Btw. I've thought of counting cycles, i-cache misses etc for a subset
of the tracked calls. It can be done for subroutine calls, by saving
the values when the call is done, and storing difference to current
values when the call returns.
For this to work also for DSP, I need to know what are DSP subroutine
call instructions, subroutine call return instruction(s) and their
Douglas, or Laurent, could you list those for me?
PS. This is needed to get reliable information about the total costs
of higher level functions. Propagating values upwards in the callgraph
in post-processing just based on proportion of call counts isn't good