tech-vector-ext@lists.riscv.org

Home Messages Hashtags Subgroups

Messages

Between

and

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

By Guy Lemieux · #787 ·

Re: Zvediv extension discussions

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

By Ken Dockser · #786 ·

Re: Zvediv extension discussions

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

By Guy Lemieux · #785 ·

Re: Zvediv extension discussions

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.

By Earl Killian · #784 ·

Re: Zvediv extension discussions

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

By Peter Lieber · #783 ·

Zvediv extension discussions

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

By Ken Dockser · #782 ·

Re: chapter 7.8. Vector Load/Store Segment Instructions

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,

By Artem Zhdanov · #781 ·

chapter 7.8. Vector Load/Store Segment Instructions

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

By Alexander Podoplelov · #780 ·

about masked-off bits for instructions vmsbf.m, vmsif.m, vmsof.m #defines

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

By lilei2@sgchip.sgcc.com.cn · #779 ·

Re: The Width of vcsr and vstart

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

By Krste Asanovic · #778 ·

Re: [RISC-V] [tech-unprivileged] [RISC-V] [tech-vector-ext] FP Trapped exceptions needed for portability

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,

By Allen Baum · #777 ·

Re: [RISC-V] [tech-unprivileged] [RISC-V] [tech-vector-ext] FP Trapped exceptions needed for portability

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.

By Krste Asanovic · #776 ·

Re: [RISC-V] [tech-unprivileged] [RISC-V] [tech-vector-ext] FP Trapped exceptions needed for portability

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

By ghost · #775 ·

Re: [RISC-V] [tech-unprivileged] [RISC-V] [tech-vector-ext] FP Trapped exceptions needed for portability

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

By Zalman Stern · #774 ·

Re: [RISC-V] [tech-unprivileged] [RISC-V] [tech-vector-ext] FP Trapped exceptions needed for portability

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

By Bruce Hoult · #773 ·

Re: [RISC-V] [tech-unprivileged] [RISC-V] [tech-vector-ext] FP Trapped exceptions needed for portability

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

By Earl Killian · #772 ·

Re: [RISC-V] [tech-unprivileged] [RISC-V] [tech-vector-ext] FP Trapped exceptions needed for portability

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

By Krste Asanovic · #771 ·

Re: [EXT] Re: [RISC-V] [tech-vector-ext] FP Trapped exceptions needed for portability

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

By Jeff Scott · #770 ·

Re: FP Trapped exceptions needed for portability

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

By andrew@... · #769 ·

FP Trapped exceptions needed for portability

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

By Ken Dockser · #768 ·

101 - 120 of 887

Home Hashtags Subgroups Terms