When compiling for RISC-V processors that support the A atomic RISC-V extension, I’m seeing an access exception when running binaries on certain RISC-V implementations when using atomics. Excerpt from the SiFive E31 Core Complex Manual:
The load-reserved (LR) and store-conditional (SC) instructions are special atomic instructions
that are only supported in data cacheable regions. As the E3 core does not have a data cache,
the LR and SC instructions will always generate a precise access exception.
I’d like to be able to target such cores with memories that do not support LR and SC (possibly by substituting AMO operations?), and I’m wondering if there are any compiler options that could support this?
If you limit yourself to the operations supported by the AMO instructions then you should not see LR/SC. If you don’t then you will. There is no option to force libcalls for just some operations (the implementations of which could then use a hash table of locks to enforce atomicity). Claiming that the E3 supports atomics when LR/SC deterministically fault on any access seems rather questionable…
I’m utilizing abstractions that are built on Rust atomic intrinsics. It does seem though that the E3 implementation violates the Atomicity Physical Memory Attributes specification:
"Atomicity PMAs describes which atomic instructions are supported in this address region. Main
memory regions must support the atomic operations required by the processors attached. I/O
regions may only support a subset or none of the processor-supported atomic operations.
Support for atomic instructions is divided into two categories: LR/SC and AMOs…"
If A is in fact divided into subsets, should this be supported by the compiler?
Main memory is what the compiler targets, so subdividing doesn’t give you the ability to target any additional legal implementations. I/O regions are outside the scope of the C abstract machine (/Rust/LLVM IR) and thus should be accessed with assembly.
Thank you for the prompt reply!