Re: [RISC-V] [tech-virt-mem] [RISC-V] [tech-vector-ext] Integer Overflow/Saturation Operations


Andy Glew Si5
 

(I've been having email problems.)


From: Andrew Waterman <andrew@...>
Sent: Monday, August 17, 2020 2:22PM
To: Tech-Virt-Mem <tech-virt-mem@...>, Andy Glew <andy.glew@...>
Subject: Re: [RISC-V] [tech-virt-mem] [RISC-V] [tech-vector-ext] Integer Overflow/Saturation Operations

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

Subject: Re: [RISC-V] [tech-virt-mem] [RISC-V] [tech-vector-ext] Integer Overflow/Saturation Operations
Date: Mon, 17 Aug 2020 14:22:25 -0700
From: Andrew Waterman <andrew@...>
To: tech-virt-mem@..., Andy Glew <andy.glew@...>


Hey Andy,

Despite the title, this thread is going to the virtual memory TG, not the vector TG.  Resend to the other list?

Andrew

On Mon, Aug 17, 2020 at 11:40 AM Andy Glew Si5 <andy.glew@...> wrote:

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

Join tech-vector-ext@lists.riscv.org to automatically receive all group messages.