toggle quoted messageShow quoted text
You're right, Allen. I didn't think that one was true. Delegation bits are presumably part of the core dispatch area and not kept somewhere else. It would be different to have exceptions depend on operational performance
counter registers, though.
On 8/20/20 9:26 PM, Allen Baum wrote:
Prvi spec v1.12 sec 3.1.12:
When the CY, TM, IR, or HPMn
bit in the mcounteren
register is clear, attempts to read the
register while executing in S-mode or U-mode will cause an illegal instruction exception. When one of these bits is set, access to the corresponding register is permitted in the next implemented privilege
mode (S-mode if implemented, otherwise U-mode).
Well, I'd be a little bit more specific: access can be conditioned on more than the CSR number, as the existence of Mcounteren CSR proves.
But, in that case, the register bit that controls access is static, held in a CSR, not dynamic and selected by the instruction, as a GPR value would do.
On Thu, Aug 20, 2020 at 12:35 PM Bill Huffman <huffman@...
The spec is set to determine writable (and required privilege) based entirely on CSR number. Anything that determined exceptions based on data or the current value of the register has been very carefully avoided. I expect
that avoidance to continue.
I'm not knowledgeable on the proposal. I'm just commenting on CSR instruction exceptions based on additional bits.
On 8/19/20 9:16 PM, Chuanhua Chang wrote:
I understand your timing concern for generating an exception based on data values. However, the concern is for data values directly read out from the general registers (GPR/FPR) by the instruction itself and the exception is generated based on these values
or some computations of these values, so the timing is tight between the data read out and computation of an exception (such as divide by zero). The concern is usually not for using data values (1 or 2 bits as control) in CSRs written by a previous instruction
or even relaxed, by a previous instruction in a different privileged mode (i.e., relaxed in terms of the length of time between the write and the use).
The current mcounteren CSR value is already used to control the generation of an exception of the read operation of the hmpcounter CSRs for S and U-mode. The timing should be similar, if we have a mcounterwen CSR and use its value to control the generation
of an exception of the write operation of a counter CSR for S and U-mode.
This is a general discussion. I am fine with dropping the S-mode direct counter update proposal based on its limited use case.