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
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol