-
Notifications
You must be signed in to change notification settings - Fork 12.1k
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
Inline assembly Unable to dynamically access RISC-V CSRs #73220
Comments
The CSR is encoded as an immediate, so it must be a value statically known at compile-time. Thus, closing as expected behavior. |
So the plan is to never allow accessing them without hard coding the assembly? |
Well, "hard coding the assembly" is what a compiler does. Otherwise this would require generating or modifying machine code at runtime, which is something much more complex than inline assembly (IIRC GCC does it for a GNU C extension, breaking non-executable stacks in the process). |
I was hoping we could have something like: fn read_csr(csr_num: usize) -> u32 {
let r: u32;
unsafe { asm!("csrr {rd}, {csr}", rd = out(reg) r, csr = csr_num) }
r
} Then the calls to the function would produce assembly like this:
I see what you mean though that it would then be possible to have: Otherwise we would have to handwrite something like this: fn read_csr(csr_num: usize) -> u32 {
let r: u32;
if csr_num == 0x10 {
unsafe { asm!("csrr {rd}, {csr}", rd = out(reg) r, csr = 0x10) }
} else if csr_num == 0x20 {
unsafe { asm!("csrr {rd}, {csr}", rd = out(reg) r, csr = 0x20) }
}
r
} |
I'm not sure, but I can suggest asking questions on https://users.rust-lang.org/. Maybe using a trait with an associated const works? |
@alistair23 I've got a proposal somewhere for LLVM and Clang builtins which would support this (as long as you can get LLVM to compile down the csr identifier to a constant). The path to upstreaming them probably involves a proper proposal to sw-dev though, and agreement on the intrinsic names. |
1926: Prepare for 64 PMP config registers r=hudson-ayers a=alistair23 ### Pull Request Overview This PR was supposed to add support for 64 PMP config register on RISC-V now that it is supported by the spec. Instead this patch has turned more info converting the riscv-csr library to use the new inline assembly macro and to allow dynamic array access to the RISC-V registers. This PR does a few things: - Converts the PMP CSRs to an array (to allow simplifying the PMP code) - Uses the new inline assembly. Unfortunately Rust won't let use access CSR dynamically like we used to (see rust-lang/rust#73220) so we now have a giant if statement to see which one to access. I couldn't see any other way to make the value const. - We also implement the register functions on specific types (u32) instead of generics. This is because with generics we can't dynamically access arrays of CSRs with the inline assembly. - Finally we clean up some of the PMP code. ### Testing Strategy None yet. ### TODO or Help Wanted Comments please, this is uglier then I would like it to be. ### Documentation Updated - [X] Updated the relevant files in `/docs`, or no updates are required. ### Formatting - [X] Ran `make prepush`. Co-authored-by: Alistair Francis <alistair.francis@wdc.com>
With the new inline assembly it would be nice to be able to read/write from a RISC-V CSR, where the CSR value is passed in via a function argument (or some other means).
Currently there is no way to access the CSR without hard coding the address in the assembly.
const
I tried this code:
Which results in this error:
in(reg)
I have tried this code:
Which results in this error:
in(csr)
and I have tried this code:
Which results in this error:
Obviously all of the above are incorrect as defined in the RFC, so that is fine.
It would be great if there is either a
in(csr)
option or theconst
option is expanded to allow non-consts (maybe anum
option or something).This seems like a common usecase to have a
read_csr(csr_num: usize) -> u32
function that can read a CSR value from a number passed in.Meta
rustc --version --verbose
:Backtrace
The text was updated successfully, but these errors were encountered: