thanks - I am OK with whichever you choose.-- ==================================================================== The information contained in this electronic mail message and any attachments

Anybody is free to use any subset of supported instructions and element widths/types. The Z names can be extended down to individual instructions/width if necessary. However, we have to guide the

Works for me. -Allen

Under the scheme I'm promulgating, it's true that you couldn't describe your hypothetical machine as implementing capital-letter "V". Perhaps it could be an RV32I_Zvbase_Zvm machine or something?

For layout reasons, I can easily imagine a vector unit that has multiply HW for vector registers, but can't easily use them to implement scalar multiply/divide. Whether someone would ever want to

We had a long discussion about how to name different portions of the vector ISA at one of the recent meetings. You can see the issue here: https://github.com/riscv/riscv-v-spec/issues/550 And the

We definitely want to sanction configurations that have different datatype support on scalar and vector. The current thinking is that the letter V means "whatever apps-profile processors want", just

I think a common embedded and FPGA scenarios will be F on the scalar side but no F on the vector side. Adding F to V is nontrivial in area, particularly for FPGAs that lack FPUs, yet an integer-only

I don’t believe the spec explicitly addresses this question, but I agree it makes sense. Alternatively, V could require M, since it doesn’t make much sense to pay for a vector unit but be too

A question to clarify. You state: RV32IV doesn’t mandate any FP hardware in the vector unit, whereas RV32IFV means both scalar and vector support single-precision, etc. This means if I

I am pleased to announce that our/SiFive's RVV intrinsic enabled GCC are open-sourced now. We put the sources on riscv's github, and the RVV intrinsics have been integrated in the riscv-gnu-toolchain,

Quad-widening ops have been moved to a separate extension, Zvqmac. I believe the intent is that the capital-V V extension supports the same FP datatypes as the scalar ISA, so e.g., RV32IV doesn’t

Apologies if this is old stuff already dismissed. But I give it a try anyway. Wouldn't it make sense to separate more complex vector instructions from more trivial ones? Already with the very first

(I've been having email problems.) From: Andrew Waterman <andrew@...> Sent: Monday, August 17, 2020 2:22PM To: Tech-Virt-Mem <tech-virt-mem@...>, Andy Glew <andy.glew@...>

thank you appreciate the distinction i agree with your answer http://bsc.es/disclaimer

Assuming it gives the IEEE-754 correct answer, definitely. Just to make sure we're not on different pages... this thread has been more about reciprocal and reciprocal square root approximations

i have a question if one implements square root using a non-restoring divide approach (which i did at one time) is this ok within the proposed/described different approaches.

On 2020-08-14 1:46 a.m., krste@... wrote: This is a policy decision ensuring reasonable limits on fragmentation in this space. To be clear, this was a tactical

Cancelled: Vector Extension Task Group Meeting This event has been cancelled. When: Friday, 14 August 2020 8:00am to 9:00am (UTC-07:00) America/Los Angeles Organizer: Krste

Apologies for late notice, but I’m going to cancel the vector TG meeting today. I still have a backlog of settled issues to incorporate in document, and do not have a set of topics worked up for