|Re: [hatari-devel] Code execution discontinuities and detecting them?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
On tiistai 19 maaliskuu 2013, Didier Plaza wrote:
> 1. Yes. Until there's no stack overflow, it's possible in 'long
> interrupt' mode.
> 2. RTI will return where the 'long interrupt' occurs.
> Moreover be carefull, there's a 'fast interrupt' mode: when the first
> word in the vector table is a JSR, the interrupt is a 'fast' one. The
> end of interrupt is done by a RTS and this kind of interrupts are not
Currently I'm checking called function ending by checking that:
- PC is on address following the instruction invoking the function
- previous PC address is RTS
E.g. in this example:
0xF01 JSR _foobar
Function "_foobar" call is noticed by PC having "_foobar" address 0x30
and instruction at previous PC address being JSR.
Return from that function is noticed by PC being at address following
the JSR instruction (at 0x02), and instruction at previous PC address
(While profiler tracks and collects info on all branches to addresses
for which there are symbols, including loop labels etc, it will collect
full costs only for subroutine calls as only with those it's possible to
know when they end... :-))
Now, if there's interrupt while in "_foobar" and following interrupt
0x001 JSR _handler
When interrupt is returned from with RTS, does PC point to
address 0x002, or to address PC had when the interrupt came?
If latter, there's a problem if interrupt happens just before
PC gets to 0xF02, address following non-interrupt JSR instruction...
(profiling code thinks "_foobar" ended and pops it out of call stack)
Otherwise, "fast interrupt" would just be recorded as normal subroutine
calls, if the address it JSRs to has a symbol for it.
(In alls cases interrupt costs would be included to full costs for
"_foobar". Normally this shouldn't be a problem as interrupt routines
shouldn't take that much CPU, and if you have symbols for their entry
points, you see their costs in the profiler output. )
> Hope this help, regards,
This seems a bit more complex than I had hoped and as the current
function call cost collecting already causes frameskipping, I
think I'll leave exception identification out unless it's needed
for correct normal subroutine call handling (i.e. adding and removing
them from call stack).