Counter for number of instruction from ISR up to a point

[RoMSI75]

I got some situations where I need to know how many instructions was executed from entry to ISR up to loading some values.
For instance, in a software serial UART (is not my case), I got an interrupt when lines goes down and after testing what cause that interrupt, I have to reload tmr0 register for the next reading and I have to substract the time spent up to reloading Tmr registers. Consider for a byte 0x00 or 0xFF I cannot sync until stop bit, and every drift in time of reading will generate some problems.

While I was using "asm" it was easy for me, but now, with uP context saving I'm never sure how many register save before entering in ISR itself. I can take a look at .lst butI have to do it everytime I recompile my project.

This can be computed at compile-time and can be easy made up to a for/while/repeat statement.

Also, some compiler instructions not to do any context saving for interrupts will be useful - but separate for high and low priority isr.

Thanks
MSI

[jpc]

you can find the number of cycles by running the ISR in the software simulator.

[RoMSI75]

you can find the number of cycles by running the ISR in the software simulator.

I can also read from .lst.
But what I want is something like:

//Next read in 18us
Tmr0:=(0x10000-(Tyc*4*18000)+(InstrCnt)) , to be sure that I don't have time drift because of those instructions spend from entry to ISR up to setup of TMR0. And I can tell that this can lead in many failure of reading peripherals, when time is sensitive and you don't have any sync base of signal.

In fact, not a counter for instructions will be useful but a counter for instruction cycles, since instructions are 1,2 or even 3 cycles.

In this way, if I have to test some more flags in int (like others sources of interrupts) or compiler want to do some magic context saving I can be sure that every time I got the correct set up of timers for ISR.

Regards,
MSI

[jpc]

in such case you would better use a timer that does not require reloading, that will eliminate this requirement which anyway will fail if ever in the code the interrupts are disabled.

[RoMSI75]

It wont work in many situation: in the same interrupt I have 3 int source:
Pin change status, pin drop low and timer.
In my example, I have to start a timer when pin port drop low for next reading in 75us, then, depending of what I got on first 8 bits I can have to read up to 128 times pin value every 50us(bit period).(don't blame me for this way of sending)
In case that pin change (0->1,1->0) I have to setup timer to make next read in 25us (half time bit period). This is for sync.
Well, if inside my ISR I have to do more stuff, compiler will automatically save registers, adding for each register saved 2 cycle (MOVFF) to ISR. This will make my values loaded in tmr to be obsolete.
But having that CyclesCount I can put a formula at loading of Tmr instead of values (and formula can be calculated at compile time). This will let me do changes inside ISR without thinking that I have to recalculate every time those values for timers. Anyway, I have to use "asm" to be sure that future implementations of newer versions will still work with my code. Having CyclesCount, I can switch to Pascal also in ISR.

This is just an example. But can be many situations that can require that. I hope that you understand now where it can be used.

I found this feature useful, that's why I put it in "Wish List" section. mE can think about for new versions, but anyway they will decide.
It's still a wish. Other things are mandatory.

All the best,
MSI