Yes, that's the consensus of the RISC-V LLVM/GNU community :)

Yes, that was the plan, Krste | On Thu, Aug 26, 2021 at 8:31 PM Kito Cheng <kito.cheng@...> wrote: | For non-priverage extension, toolchain can control version for each | extension by

Should I assume that for the ratified vector spec simply 'v' can be specified? And that a version number is only needed to refer to a pre-ratified version of the vector spec? Greg

it sounds like we are aligned Get BlueMail for Android On Aug 26, 2021, at 8:27 PM, Kito Cheng <kito.cheng@...> wrote:

let's create a top sheet and add this please. philipp is working on a review proposal. likely more like tech-announce for 2 weeks and notify TSC and the board. etc Get BlueMail for Android On Aug 26,

Hi All, The KVM RISC-V AIA support has been successfully validated with AIA IMSIC virtualization features emulated by QEMU RISC-V. This means KVM RISC-V Guest Linux works perfectly fine with

Hi Allen: Thanks for the information :) For non-priverage extension, toolchain can control version for each extension by ISA string, e.g. -march=rv64gcv0p10 to specify vector extension with version

Hi Mark: It sounds like we can expect all privilege stuff like machine-level ISA, supervisor ISA will become several extensions at privilege spec 1.12, and then those extensions can be controlled by

.Note that the Imperas OVPsim simulator, and the tests they've written for it, can already specify priv spec version numbers (and vector spec version numbers).

+Philipp Tomsich

all the specs will have unique extension names. it is also possible to have rollup extension names like we have for crypto like Zk. I suggest we make the options match the extension names and if

Hi : I am Kito Cheng, one of the RISC-V open source toolchain developer. Recently RISC-V LLVM and RISC-V GNU toolchain community are discussing how to version control the privilege spec stuff - which

That's true. Regardless of fetching instructions or data, using virtual addresses is always a critical path. It is not good to add any additional logic to this path. But this is the most friendly

That's right.

Not sure that was the intention. But someone with more authority may be able to shed some light. IIUC the SV39 address space is shared between S-mode and U-mode. Effectively this would mean the top

I believe the two text are complementary. The first is saying what value is stored in the destination register - e.g. pc and rd by JALR - this is the sign extended value. The second text is what is

Oops, have we found a contradiction in the spec? If we sign-extend the 32-bit PC 0x80000000 as described in the Machine-level ISA, then the 64-bit VA will not be in the "lowest 4GiB of the address

Specifically for UXLEN which was the op, section 4.1.1.1 provides this guidance on effective address: "If UXLEN < SXLEN, user-mode instruction-fetch addresses and load and store effective addresses

Yes, you’re right. Either option will depend on how the hardware extends the address. I assumed zero-extending it would be the default way, but that isn’t the case. In fact, the spec have

This will affect the hardware design: when the processor generates a instruction or data fetch request in U mode (XLEN 32) , how to extend the MSBs of the virtual address. For example, when U mode