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

Feature/formally parse riscv isa #2028

Open
wants to merge 7 commits into
base: main
Choose a base branch
from

Conversation

perigoso
Copy link
Contributor

Detailed description

This is a cherry-pick of a couple commits from #1399 that stand on their own as general improvements.

This adds more compreensive parsing of the RISC-V ISA from the misa register when available, this is used to show a more complete ISA when a target is probed.

Example with a RP2350 which is the only RISC-V target I have on hand:

before:

Available Targets:
No. Att Driver
 1      RP2350 rv32
 2      RP2350 rv32

after:

Available Targets:
No. Att Driver
 1      RP2350 rv32imac
 2      RP2350 rv32imac

The RP2350's formal ISA according to the datasheet is rv32imac_zicsr_zifencei_zba_zbb_zbs_zbkb (or rv32ima_zicsr_zifencei_zba_zbb_zbs_zbkb_zca_zcb_zcmp with the most recent interpretation), so the BMP's parsing is correct.

It's important to note, this only interprets the ISA standard ratified extensions, reserved extension bits are ignored for now, and since Z/X/S extensions cannot easily be detected (There's no CSR for them) they are "ignored" too.

Technically the presence of the 'B' extension can be interpreted as the Zba, Zbb, and Zbs extensions being available, but in the interest of a cleaner ISA string we ignore it too.

The 'I' is not directly intepreted because it is a base ISA, and is implicit unless the 'E' base ISA is set which we do check for. The 'E' bit is always the complement of 'I' only one is ever set, and one must be set.

This implementation could be cleaned up and be made much more efficient, but it works as is and can be improved later, submitting as is in the interest of getting merged before the v2.0 release

Your checklist for this pull request

Closing issues

write_char writes a single char into a char buffer at the provided offset, returns the offset incremented by 1
Memory safety safeguards are in place, if no buffer is provided, a buffer size of 0 is given, or the offset is out of bounds of the buffer, the buffer is not accessed, but the offset is still incremented

Target use case is using in special print functions behaving similar to snprintf
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

Successfully merging this pull request may close these issues.

1 participant