CLR TR0 ;Stop timer - No.
You -never- stop the timer. You jump in and out of the wagon on the run al the time.

The below example doesn't check for overflow conditions (assumes call rather soon after the interrupt and "low byte" of the reload (LOW TID0) small as there's no TH0 overflow checking.)

PUSH PSW
PUSH ACC
MOV TH0,#HIGH -TID0
MOV A,TL0 ; Freeze timer in ACC
ADD A,#(LOW -TID0) + ADJ ;"reload" and "cycle adjust"
MOV TL0,A ; Rewrite timer 2 CYCLES LATER!

You write to the clock 2 cycles later than you read it. The clock should have grown by two in the meantime, if you write "reset time" plus state of the clock 2 instructions ago you miss that time. That's what ADJ corrects - it contains time required to update TL0. (note only one MOV will apply when you count cycles for ADJ)

Of course you COULD stop the timer and perform all the maths on it like on a static, still 16bit value. Just note ADJ will suddenly become quite a large number (number of cycles wasted from CLR TR0 to SETB TR0).


By the way, how does interrupt priority change work "on the run"? Will something like this:

SETB PT0
MOV A,TL0
ADD A,#(LOW -TID0) + ADJ
MOV TL0,A
CLR PT0
disable all other interrupts from kicking in during the time-critical phase while allowing high-priority ones to override this interrupt earlier or later?