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

As Andrew says, verification/compliance concerns outweighed allowing more flexible definition. Also, the fixed 7b implementation was seen as being cheap to provide even if more accurate

The task group did consider that possibility but concluded that forcing compatibility is more important. As Bill points out, more precise (or flexibly precise) variants can be defined in the future,