Done. Thanks Roger. From: Roger Espasa <roger.espasa@...> Date: Sunday, October 4, 2020 at 12:49 PM To: Joseph Rahmeh <Joseph.Rahmeh@...> Cc: "tech-vector-ext@..." <tech-vector-ext@...>, Robert

Joseph, May I suggest you open a git issue here: https://github.com/riscv/riscv-v-spec/issues with these two questions? It will help better tracking and will ensure whatever the resolution is, it does

Should vid.v raise an illegal instruction exception when masked and when the destination group overlaps v0 ? Should vid.v raise an illegal instruction exception when vstart > 0 ?

Krste

I will add my thoughts related to "embedded" imprecise: Why embedded specifically? Linux handles GPUs as coprocessors. My understanding is that by their nature, the internal state

Is there already a doc/issue specific to this imprecise handling that we can reference before and during the meeting?

Reminder we’ll be meeting tomorrow in usual slot. I’d like to spend the time discussing imprecise trap handling for embedded vector systems. Hopefully, we can all see the new correct link on

Never say never. Appears to be the mantra for V extension. Yes, the intent is that the V specification mandates LMUL of 8, 4 and 1. Even for minimal systems of VLEN=128; not only for

Hi Joseph, Thanks for the clarification. The wording in the spec is admittedly vague: "LMUL can have integer values 1,2,4,8.", etc. My understanding of the intent is that all implementations must

Hi Nick, Thanks for the reply. I was not asking for non-power of 2 LMUL. I was asking about LMUL values not supported by some implementation. Let’s say that for SEW=128, an implementation

Sorry, in case it wasn't clear: typo it's not too much of a burden.

Hi Joseph, Thanks for your comments. I apologize, but I don't fully understand your proposal, or the problem it solves. To help explain my confusion, here are two thoughts. The supported LMUL (and

In the latest vector proposal (draft of version 1.0), there is the following restriction on widening instructions (section 11.2) For all widening instructions, the destination EEW and EMUL values

I am in favour of effectively weakening the scalar/vector vector/scalar load/load order requirement. However, this cannot be performed in isolation  without regard to the rest of the RVWMO

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

Nick fowarded the old deprecated calendar. https://sites.google.com/a/riscv.org/risc-v-staff/home/tech-groups-cal Is the new unified tech group calendar. It is very hard to find, we're working on

It looks like there are two calendars – one on the risc-v site, and one on google (someone else sent to me). And the ZOOM meeting invites are not the same between them :\ -Cohen From: Nick

Hi Cohen, I can see the calendar here: https://lists.riscv.org/g/tech-vector-ext/calendar Unfortunately, due to a conflict I can only rarely attend the TG meeting. Best, Nick

Can you publish a link to what the Google Calendar is, or the TG meeting link? There are no links on this site to any of that information.

You got my thumbs up! Definitely "something similar" and better that my more cryptic proposal. Thanks you Cohen for raising these concerns and Nick for moving this along so