Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Notation for branch/jump target ranges might be misleading #1781

Open
WorldofJARcraft opened this issue Dec 19, 2024 · 0 comments
Open

Notation for branch/jump target ranges might be misleading #1781

WorldofJARcraft opened this issue Dec 19, 2024 · 0 comments

Comments

@WorldofJARcraft
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant