CSR time and timeh registers

[mvlamar]

Hi,
I think it would be very nice if the CSR registers time (3073) and timeh (3201) could be implemented, as simple as
long csr_time = System.currentTimeMillis();

Suggestion:
Maybe, to reduce the computational complexity, instead of continuously showing their values in the register bank panel, these values can be updated only when these registers are read by csrr t0, 3073 or csrr t0, 3201 instructions.

We are implementing these registers on RISC-V hardware (FPGA), and this improvement in Rars would be nice to maintain the "compatibility".
Of course, there are many other issues involved, such as step-by-step execution and back step tracking, as you said before, but we can deal with this in sequence. :)

[TheThirdOne]

I am totally willing to implement time and timeh; because I was unsure of what behavior was best I was leaving off actually implementing it until someone needed it. So now that you need it I should implement it in some form.

Technically speaking, just using system time is a very simple solution that would take a total of ~10 lines. Another solution of similar complexity would just be mirroring instret or cycles.

Those two potential solutions would have different behavior when interactively debugging.

I would leave it to you to decide between those two or suggest a third option. I see pros and cons to both options for various people, but you have a concrete use case so it should be more clear.

[mvlamar]

Since Chapter 10 of the RISC-V Instruction Set Manual (version 20190608) defines the time and timeh registers as a real-time clock, I think using a millisecond counter and keeping them independent of the cycle and instret registers (in rather than mirroring them) is the best choice.
The decision to take cycle = instret is OK because it defines that Rars emulates a single-cycle processor. However, doing time = cycle forces the clock frequency of a theoretical processor to be 1kHz. It may be interesting to give Rars some degree of freedom. Thinking about educational purposes, it is very interesting to allow some performance analysis experiments. Therefore, using system time (a millisecond counter from January 1, 1970) is the best option in my opinion.
Perhaps step-by-step debugging should ignore this. The focus of debugging is to fix the code, not measure its performance.

[TheThirdOne]

I don't believe the specification defines anything about how long a single tick for the time register is.

While 1ms / tick seems reasonable, I think a wide range of periods would be compliant.

However, doing time = cycle forces the clock frequency of a theoretical processor to be 1kHz.

I believe making time = cycles would only restrict it to a hypothetical single stage, fixed frequency processor.

[TheThirdOne]

time and timeh are now implemented by just using system time. Rather than update only when read, they update their values at the end of each cycle.

You should be able to check it out in the latest continuous release. If you would like a stable release I can do that, but I would like to make the next release include support for doubles which will probably take at least a week.

[mvlamar]

Hi,
It is perfect!
Thank you!