The current vector TG is only tasked with one more deliverable, which is the IEEE FP16 half-precision extensions (Zvfh, Zvfhmin). This is effectively already defined in ratified specification, and so

Thanks for spotting the oversight. The spec was updated to indicate these should be treated as XLEN-bit wide registers. There is no effective difference right now given that upper bits are not current

I'll note that ARM appears to detect tininess before rounding, while x86 does so after rounding. Also, current ARM compilers don't support exception trapping on AArch64. https://developer.arm.com/docu

Yes, this would be the obvious path to take. Some use cases, including maybe this one, might prefer FP traps to be horizontal into user mode. There is the old MIPS FPU pipeline trick of conservative e

| Reviving this old thread with a question and a suggestion: | Question: What is the use case for supporting non-idempotent memory in a RISC-V Vector implementation as a part of a general-purpose | ri

Earlier Intel Larrabee design had variant that required loop around unsuccessful gather according to mask bits. I believe some folks on this list were responsible for that... Krste

A paranoid hypervisor could restrict ff loads to always reduce to vl=1, or only after x failed probes, for example. Krste

SVE uses a special dedicated FFR register to hold these first-faulting load mask bits. RVV just reuses vector length register in a natural way. Krste

The primary reason was lack of encoding space for non-unit-stride fault-on-first instructions. The security concern was being able to probe addresses to find accessible regions without free of being k

Not necessarily with a larger mask register specifier. For example, with 3b mask register specifier, we could expand to encode v0-v6 as mask sources with 111 meaning unmasked. Krste

| From: Grigorios Magklis <grigorios.magklis@...> | Sent: Tuesday, November 16, 2021 12:03 PM | What is the thinking for when we go to >32-bit encodings with respect to vtype | and masks

|| 1) Mandate all implementations raise an illegal exception in this || case. This is my preferred route, as this would be a minor errata for || existing implementations (doesn't affect software), and

| From an ISA definition point of view it doesn't make sense to forbid properly formed operations to benefit a | specific hardware implementation. It's an ugly hack. A common goal in ISA design is avo

In this case, the trap cause can be determined by looking at the vtype value and the instruction encoding (most only need to look at instruction encoding), independent of implementation. No vtype prob

I guess simpler examples are anytime you use v0 as mask and a data source. These aren't useful use-cases, so existing software shouldn't have been doing this (except test code). Krste | On Mon, Nov 15

I'm not sure if C intrinsics can generate this case, but there are other cases where dynamic value settings can result in illegal instruction traps, so the result would be the same that implementation

I went with #3 in the updated text - this is the smallest delta from the frozen spec. Note that the worst case was something like: vfwmacc.vv v0, v0, v0, v0.t with SEW=32b, v0 is read/written as a 64b

There’s no benefit to setting vill versus just taking a trap in this case. Vill is there so we don’t have to add the first trap on a write of a particular data value, and also to provide a discovery m

I'm OK with going with #3 - it provides most flexibility to deal with in future, even if we just go with illegal instruction exception, and avoids adding tests to the compatibility suite. Krste | On M

| We do have a choice of: | 1) Mandate all implementations raise an illegal exception in this | case. This is my preferred route, as this would be a minor errata for | existing implementations (doesn'