On 2023-12-15 18:37, Maciej W. Rozycki wrote:
On Fri, 15 Dec 2023, Johnny Billquist wrote:
983136 is pretty close to 1000000. However, without looking at the
code, isn't
that the diagnostics timecounter? Now used for anything really
related to time
keeping, but just for some other information, like sampling the state
of the
cpu and so on?
It's just a free-running counter, as good as any. The KA46 has no ICR.
Sortof. ICR and NICR are not required to exist. A machine is allowed to
have a subset implementation of ICCS, only capable of generating an
interrupt every 10 ms with no further control. Which is still the normal
clock used as a source for time in the OS, if I'm not completely confused.
The code in clock.c always sets NICR to -10000, which basically means
that we are requesting it to interrupt every 10 ms. So in case the CPU
only have the ICCS subset, we will also be getting interrupts every 10 ms.
So that's the basic clock the system runs from. Oh, and I should maybe
mention that the VARM calls out that the precision of this clock is only
required to be to 0.01 % accuracy, so a drift of up to 8.64 seconds per
day are within specs. (VARM page 8-22, section 8.3.5 Interval Clock
Register).
More things while I'm at it: VAX_BTYP_46 is not using ICR to find the
current time, but instead have another function to work out time at some
higher precision. I haven't gone and chased through that bit.
What is perhaps worse is that if you have VAX_BTYP_48 we're not calling
tc_init() for any kind of clock, which seems broken.
So in the end, what we have is that for most machines, we're getting a
higher resolution clock based on ICR. We basically have the clock tick,
which gives something at 10 ms steps, and then we add in what ICR is at
the moment. For CPUs that don't have an ICR, the clock will just be at
the 10 ms resolution and that's it.
With the exception of the VAX_BTYP_46, which uses another source, that is.
But disregarding that one for now, as I'm not going to dive down that
rabbit hole this moment. The vax_mfpr_get_counter() function seems
potentially broken. If getticks() returns a negative value, we seem to
be potentially getting into a weird condition where we only slowly are
moving forward from prev_hardclock, which isn't even initialized.
I need to think a bit more about that code, and maybe do some tests...
Johnny