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.)

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,

As it stands, the spec requires a specific result for every argument. There's no flexibility at all. Particularly since these are single-input instructions, there's opcode space to allow for more

As it stands, I think the spec prevents an implementer from being more accurate than described, right? Should the spec specify "accurate to at least 7 bits" instead? I could envision an embedded

On 8/13/20 2:33 PM, Andrew Waterman wrote: Happily, yes. :-) Sounds good. Bill

Hopefully because we've converged, not simply due to exhaustion :) Thanks. I'm going to merge the pull request now, but additional feedback is still welcome, of course.

I think maybe I'm done complaining. :-) Except that the initial paragraph on recip operation needs the words "concatenated and" removed. Bill On 8/13/20 2:11 PM, Andrew Waterman wrote: