I'm also unclear of the "identifier" you mention for other unmentioned option value (e.g. your 64b cache block size example). Who is the consumer of that identifier? Is this a value you would expect

If you're looking at the same thing I was looking at: the "extension names" are not extensions, in the usual sense. They are names for the values of architectural options of extensions that already

Hi All, First off, please redirect me where the most appropriate forum is to discuss this topic. I am casting a fairly wide net, but that's just trying to cover those who are impacted. We can convene

Okay, I would try the fast-track extension process. -- Best Regards Guo Ren

I suspect someone could pursue standardization of this via the fast-track extension process. Greg

Make rv32 support svpbmt & napot by reducing the PPN witdth (sv32p34 -> sv32p31). RISC-V 32bit also requires svpbmt in cost-down chip embedded scenarios, and their RAM is limited (No more than 1GB).

This is a call for chair and vice-chair candidates for the recently created Performance Analysis SIG (umbrella: Privileged Software HC) All candidates must submit a biography (bio) and statements of

Oops, I guess the web interface doesn't include the text from the message I was responding to. Here it is, from Krste: | I would like a clarification on whether this replaces the existing NMI, or are

Reviving this old thread. What is the status of this proposal? I'd like to explore using RNMIs for performance counter overflow interrupts, in order to support profiling while interrupts are masked.

ok, thanks John, I've done the rewording. Tariq -- Tariq Kurd | Chief CPU Architect | Codasip UK Design Centre | www.codasip.com

Tariq Kurd wrote: Yes, let's assume bit 2 is allocated for this purpose, in mstateen0, hstateen0, and sstateen0. We'll probably change the wording later, but for now, replace the word _encodings_ by

Mark wrote: We expect people to implement the new Zcm* extensions together with Zca and Zcb. Zca is the subset of C that drops the compressed instructions for double-precision floating-point loads

Please explain to me why we would not want implementers to implement Zc* and not C. I am not sure I understand the use cases and workloads well. Am I misunderstanding? I understand that implementers

OK, thanks everyone, interesting debate. BTW it's not only Zcmt which has conflicting opcodes with C (encoding C.FSD, C.FSDSP, C.FLD, C.FLDSP), it's also the case for all Zcm* (Zcmb Zcmp Zcmpe

I wrote: Correction: Zca is a subset of C; Zcb is not. - John Hauser

Greg Favor wrote: Actually, there's no conflict between Zcmt and the D extension. The conflict is between Zcmt and the C extension, because it's the C extension that defines the compressed instruction

OK, I interpret that as "define no spec before its time". I suspect we can live with that.

Not required. Just an option for the seemingly (?) rare design that implements both extensions and hence needs a bit to control which is enabled (and the other is disabled) - ASSUMING that there is

Greg, you said: The spec for Msstateen says: It sounds like this is that rare case: Smstateem enable bit is required because they are incompatible, So it must control both the access to the CSRs and

Thanks Greg. Would like to know what drove that decision. Jeff