LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
தமிழ்நேரம்

Carry, Borrow, Overflow bit for integer Arithmetics

Status: Declined

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.

 

When it comes to integer addition, subtraction I would like to have one more bit for input and output. This will help me to achieve N byte (width) addition or subtraction. Please see the diagram for details.

 

 

 

Some times when there is an overflow, I would like to have saturated value or sometimes modulo value. With the current behavior we get modulo addition only. if we have this bit output, we can even decide the output to be saturated value(FF) or modulo value. 

 

 

Since basic arithmetic functions are polymorphic in nature. we can add this two terminals as optional terminals.  

 

New Idea.png

அன்புடன்
தமிழ் நேரம்
முதல் இந்திய ஆய்வுமெகபொப சிற்பி
சோதனைநிறுத்தம் சிற்பி
மற்ற சான்றிதழ்கள்
யாதும் ஊரே! யாவரும் கேளிர்!!

3 Comments
JLewis
Member

The fixed-point data type is our current solution for this sort of functionality, but there are gaps and it is geared toward FPGA use cases. I'll summarize what we have now, then I would be interested in how exactly you would use the proposed functionality.

  • Overflow reporting and handling is provided by functions supporting the fixed-point (FXP) data type. So in the add and subtract examples above you can select Properties and configure the output to be a fixed-point signed integer type, which we write as <+-,8,8> (signed, word length 8, integer word length 8). Then you can configure the overflow modes. I do understand that this is not what you're requesting, and that the Add Array Elements doesn't currently support FXP.
  • The High Throughput Math functions available under FPGA targets include carry/borrow capabilities. They also provide larger than 64-bit addition capability via Boolean arrays.

Questions for you: Your examples show U8 types. How would you use the carry in/out with that type (as opposed to just going to the next larger type)? I can see how it's useful for when you need to exceed 64 bits, but some examples for what you would do with smaller types would be helpful. Is this primarily for use on the desktop or for developing apps for other targets?

Does the FXP data type address your overflow use cases? There are functionality gaps and some awkward conversions involved if you really want to stay with integers throughout, but we could address those as usability issues and try to make the integer/FXP experience more seamless and complete. We might be able to allow configuration of overflow modes for integers, for example, but if you want an overflow status output you would have to go to a FXP output type to take advantage of the embedded overflow bit.

LuI
Active Participant
Active Participant

I am using especially the add_array node quite extensive _as_is_ and whenever I need a real addition I have cghanged to a wider data type.

So if your suggestion was introduced into LV than the default mode should stay as is.

BTW, your suggested output of the add_array should be a numeric rather than a boolean and should contain the overflown part of the sum 😉

 

Greetings from Germany!
--
Uwe

Darren
Proven Zealot
Status changed to: Declined

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.