One reason why I would like to keep the wrap/nonfat rating form for 2X widening multiply accumulate:

 last time I checked  none of the standard of widely used programming languages like C  or C++ have standard  saturation support.

 Sure,  there are plenty of nonstandard C extensions from various DSP companies that provide saturating support,  just like there are similar extensions that provide fixed point. IMHO  it is interesting how many different forms of fixed point are present.   similarly, in C++ you can design your own template types for saturation and/or fixed point.   but as far as I know no single such library has taken over;  no single such library is part of standard C++.

 if you want to use portable code, you can write things like

uint8_t a, b;

uint16_t c;

c += a*b; // does u16 += (u8 = u8*u8*)

or

c+= (uint16_t)a * (uint16_t)b;  // does u16 += u**u8

 i.e. if you have the  non-saturating form you can use portable code, and a generic compiler like GCC can optimize it,  if you have a 2X widening multiply accumulate.

---

---

From: Andy Glew <andy.glew@...>
Sent: Sunday, August 16, 2020 8:29PM
To: Cds <cohen.steed@...>
Subject: Re: [RISC-V] [tech-vector-ext] Integer Overflow/Saturation Operations

 

-------- Forwarded Message --------

Subject:	Re: [RISC-V] [tech-vector-ext] Integer Overflow/Saturation Operations
Date:	Sun, 16 Aug 2020 20:29:42 -0700
From:	Andy Glew Si5 <andy.glew@...>
Organization:	SiFive
To:	CDS <cohen.steed@...>

I would be fine  to have the ISA define saturating  2X widening multiply accumulate,  in addition to the  non-saturating "wrap"  form that you object to.

I think it would be bad to have the ISA define only saturating 2X widening multiply accumulate.

(sorry if this was sent twice.)

---

From: Cds <cohen.steed@...>
Sent: Monday, August 10, 2020 6:36AM
To: Tech-Vector-Ext <tech-vector-ext@...>
Subject: Re: [RISC-V] [tech-vector-ext] Integer Overflow/Saturation Operations

 

On 8/10/2020 6:36 AM, CDS wrote:

Andy,

Thank you for your response.

The concern I'm raising is less about "How do I avoid overflow?" and more about "Why are we avoiding the specification of saturating instructions, or an overflow flag?"

I can always avoid overflow by using smaller numbers, or using a larger data path. Sometimes, I won't know that I've exceeded my data path limits. Sure, design for safe margins, yet we rely on hardware signaling to inform us when we've gone beyond a hard limit. Another way of stating the question: Why NOT have saturation or overflow for these instructions? The alternative is a silent data corruption.

--- Sorry: Typos (Speech-Os?) Writing Errors <= Speech Recognition <= Computeritis