You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Consider the following text from the C extension (chapter 28.4, page 168 in the latest release, emphasis by me):
C.BEQZ performs conditional control transfers. The offset is sign-extended and added to the pc to form
the branch target address. It can therefore target a ±256 B range. C.BEQZ takes the branch if the
value in register rs1′ is zero. It expands to beq rs1′, x0, offset.
The C.BEQZ instruction's branch target is actually in the interval [-256, +254]; trying to encode +256 as the immediate is interpreted as -256 due to overflow into bit 8, see this example.
Thus, I believe it would be beneficial to state such intervals explicitly. I chose CB-type instructions as an example here; variations of this notation above are used for other types of encodings as well (e.g., C.JALR).
Implementing the bounds of the branch targets correctly is crucial for assemblers, linkers and loaders. For example, when I implemented RISC-V relocations for the zephyr RTOS, I initially used the incorrect interval [-254, +254] for checking CB-type relocations for truncation, causing relocation to fail for valid code. Thus, I believe changing the notation as above might benefit similar projects in the future.
If you agree this is useful, I will prepare a pull request with the necessary changes.
The text was updated successfully, but these errors were encountered:
Consider the following text from the
C
extension (chapter 28.4, page 168 in the latest release, emphasis by me):The
C.BEQZ
instruction's branch target is actually in the interval [-256, +254]; trying to encode +256 as the immediate is interpreted as -256 due to overflow into bit 8, see this example.Thus, I believe it would be beneficial to state such intervals explicitly. I chose CB-type instructions as an example here; variations of this notation above are used for other types of encodings as well (e.g.,
C.JALR
).Implementing the bounds of the branch targets correctly is crucial for assemblers, linkers and loaders. For example, when I implemented RISC-V relocations for the zephyr RTOS, I initially used the incorrect interval [-254, +254] for checking CB-type relocations for truncation, causing relocation to fail for valid code. Thus, I believe changing the notation as above might benefit similar projects in the future.
If you agree this is useful, I will prepare a pull request with the necessary changes.
The text was updated successfully, but these errors were encountered: