Closed james-ball-qualcomm closed 1 month ago
Hi James,
I propose to add a note that an implementation "can decide to align PC" accordingly to IALIGN, but I would not recommend any forcing.
From my side if SW is adding a unaligned address in the Vector Table it is a SW error, as it is branching to an unaligned address. And this will then be covered by unprivileged spec chapter 1.5
Masking bottom bit from my side could lead to execute some instructions badly executed without seeing the initial issue..
The existing pseudo-code already shows forcing the LSB to 0 (with the implicit assumption of IALIGN=16). If you don't force the 1 LSB (IALIGN=16) or 2 LSBs (IALIGN=32) to zero then what happens if a programmer puts non-zero values there? Presumably it would cause a misaligned instruction address exception since it is a hardware state machine and not a jump instruction.
So, I recommend that the pseudo-code and the text both make it clear that implementations must ignore the bottom 1 or 2 LSBs (depending on IALIGN).
Maybe we can talk about this at the next Fast Interrupt TG meeting since I'm not sure I fully understand your comments and perspective?
Can we close this now that the related PR has been accepted and merged into the main branch?
PR done and merged. can be close
In "smclicshv Changes to xtvec CSR Mode for CLIC" section, there is pseudo-code showing the least-significant bit of the vector table entry is forced to zero when the hart fetches the entry from the table (the "&~1" in the pseudo-code).
I have two related issues related to this: