Great points Ken & Earl. One thing I'll point out is that this does not necessarily have much to do with EDIV specifically. For example, the main goal of EDIV is to support smaller element dot

Thanks folks, these are all very good points. Earl: I absolutely agree that these extensions (like all RISC-V extensions) need to be developed based on real-world needs and need to be able to show

The AMX extension for AVX512 is an interesting approach.... https://en.wikichip.org/wiki/intel/dl_boost

I hope that these discussions will begin with algorithms and applications that need the additional performance, and proceed to analyze how proposed instructions address the greater need.

In the Graphics/ML SIG, we also discussed matrix operations as well. We talked about a single matrix opcode with various functions like vector-matrix, matrix-matrix, and dot product functions, among

I am hearing renewed interest in adding a dot-product extension to the RISC-V Vectors. This includes everything from adding a handful of FP and Int dot-product instructions all the way to completing

Hello! As far as I understand, there is no separate field for decoding a segment instruction other than NF. Therefore, those instructions are considered segmented if NFIELDS > 1 (nf != 0). 01.02.2022,

Hello! I have a question about vector segment load and stores. In table 14 we have NFIELDS from 1 to 8. In paragraphes 7.8.1-3 we have format like vlseg<nf>e<eew>.v vd, (rs1),

Hi， I have a question about masked-off bits. I am not sure what is the behavior of destination inactive masked-off bits for instructions vmsbf.m, vmsif.m, vmsof.m. Does the "xxxx" means we can fill

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

IF the Trap-on-masked-fflags op isn't executed often, then a 4 instruction sequence (CSRRD FFLAGS, ANDI, BNE, .+4, ECALL) would do that, so there is a workaround. IF that has a performance impact,

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.

Along with this, I'd suggest considering an extension that consists of just one instruction: trap if (FP flags & mask in instruction) is non-zero. I'm not a hardware designer, but it seems to me that

I’d suggest identifying important use cases for this. I’d also be looking at software techniques where the compiler inserts checks to provide the necessary support for the use cases

What's the use-case for trapping on inexact (or even caring about it) in FP? Using doubles as 53 bit integers? I did that myself in accounting software back in the 80s and 90s, but it's a bit

The question I have is whether having this in scalar only would be sufficient? If porting an application were to need exception traps, it seems plausible to disable compiler vectorization. The MIPS

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

Completely agree. Was very happy RISC-V did not include FPU exceptions. Jeff

Defining a standard extension that provides precise traps on FP exceptions seems like a reasonable thing to do, if only to facilitate the use case you mention in a standard way. The strategy would

While I understand that it had been decided long ago (relatively speaking) that RISC-V would not support trapping on floating-point exceptions, I am wondering if we need to revisit this. I have heard