If you are looking for expected dates they are always in the spec status spreadsheet at: https://docs.google.com/spreadsheets/d/1iDXsvDhu8uRtiss0YazlioBBEV9Jrq_o01E59QdmkE0/edit?usp=sharing if it is

Hi Krste and Andrew, What is the rough plan for rvv v1.0 release? I searched vector-ext mailing list but can’t find the info I want. Thanks Weiwei

I think we'll be spending a chunk of time on mask layout and implementation issues. See you then, Krste

👍

This is issue #601. It was pointed out that *e7 (estimate to 7 bits) suffix on mnemonic is easily confused with e32 (element size 32) on other mnemonics. This is probably one we can handle on email

Date: 2020/11/13 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger Espasa Number of Attendees: ~22 Current issues on github: https://github.com/riscv/riscv-v-spec Issues

Because there is no "official" BF16 standard (beyond interchange format) and because other vendors have made incompatible choices (so no de-facto standard either), we will need to define the RISC-V

In support of Open Source Software and publicly released modeling schemes, does the Vector Task Group have a recommendation for arithmetic reference? The published ISSs can provide checking results

Also, reminder we'll be meeting tomorrow (Friday Nov 13) as per calendar entry (7 hours from now), Krste Date: 2020/11/06 Task Group: Vector Extension Chair: Krste Asanovic Co-Chair: Roger

This sounds right to me as well. No use making a special case for strided stores with rs2=x0. Bill

I understand now. I'm on board iff the memory consistency model experts assent.

There’s a comment about this in spec already. But note that this would be in a case where you're relying on having multiple accesses in a non-deterministic order to one memory location, which is

Sorry, slightly off topic, but what was the rationale for I guess I'm thinking about the possibility of a toolchain relaxing `li, x1, 0; inst x1` into `inst x0`.

I made an error copied from my meeting notes - this should be when rs2=x0 (i.e., the stride value), Krste

These are all supported with ordered scatters/gathers to/from a single address. We wanted to remove ordering requirements from all other vector load/store types. Krste

I think this is a bad idea for both loads and stores. If the intent is a single load or single store, then there should be another way to do it. Using vector loads/stores with stride=0 is one way to

Also on github as issue #595 In our earlier TG discussion in 9/18 meeting, we were in favor of allowing vector strided load instructions with rs1=x0 to perform fewer memory accesses than the number

The key insight from the 21264 design is that the valid bits are cleared periodically. I appreciate that you were willing to meet me more than halfway, but I actually think your original idea would

We'll meet per the calendar entry. Agenda is to go over any remaining unsettled open issues, Krste

I see it's called a "stWait table" in the hardware reference manual. I see how that works for waiting loads. I'm guessing that you're thinking of a PC based table here that remembers that certain