-
Notifications
You must be signed in to change notification settings - Fork 275
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
More RISC-V instructions in core::arch
#1271
Conversation
todo: wait before supervisor extension in rustc risc-v target is available (e.g. when we're developing kernel modules or kernels themselves, S extension is enabled) sinval.vma instructions FENCE.I instruction
adds `riscv64` module
r? @Amanieu (rust-highfive has picked a reviewer for you, use r? to override) |
3ed8266
to
a8d1061
Compare
modify core arch docs
a8d1061
to
ebe0141
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM other than the module name issue.
I modified r? @Amanieu |
2e97688
to
fb4607c
Compare
crates/core_arch/src/riscv32/mod.rs
Outdated
/// advancing the `pc` and incrementing any applicable performance counters. | ||
#[inline] | ||
pub fn nop() { | ||
unsafe { asm!("nop") } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the asm!
blocks here should use nostack
since they don't push anything to the stack.
Additionally:
- Most should use
nomem
, except for loads which should usereadonly
and stores which should use neither.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I'll check it out.
There are many privileged memory fences as well, I'd also figure it out in these intrinsic functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point about the fences, those should not use nomem
/readonly
because they need to act as a compiler fence.
crates/core_arch/src/mod.rs
Outdated
@@ -264,7 +276,11 @@ mod arm; | |||
|
|||
#[cfg(any(target_arch = "riscv32", target_arch = "riscv64", doc))] | |||
#[doc(cfg(any(target_arch = "riscv32", target_arch = "riscv64")))] | |||
mod riscv; | |||
mod riscv32; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps calling this riscv_shared
(like arm_shared
) makes more sense?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense, it would be a more common module system design.
rename internal riscv32 module to riscv_shared
fb4607c
to
d69b776
Compare
Hello! I renamed internal shared riscv module to
r? @Amanieu |
This pull request includes:
Module
riscv64
is added to include RV64 only virtual machine memory instructions. RV64 supports all RV32 virtual machine instructions, it's implemented like:(Edit: implemented like
pub use crate::core_arch::riscv32::*;
etc)Most of implemented functions are marked as unsafe. That's because these functions either load or store effectively into raw pointer (hlv, hlvx and hsv instructions), or would effect how the RISC-V core handles page memory translation (memory management fences and cache invalidations).
Specifically, here's a list of implemented instruction functions from updated RISC-V core arch module:
Marked as draft: more polishing on documents(done), and decide whether #[must_use] is necessary on virtual machine memory loads.(ref: ptr::read & ptr::write, does not put #[must_use] by now)