Why No Rollover for While Loop i I32

[JScherer]

There are various articles showing that a while loop's i counter will not rollover after it reaches max value. See below:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000001DcZJSA0&l=en-US

I understand that historically this hasn't been an issue for most developers as many programs will not have loops that cycle so many times. However, I feel like this is unexpected behavior as everywhere else in LabVIEW adding 1 to a maxed I32 would result in 0. Is there a reason why the loop counter should not follow the same rule?

[FireFist-Redhawk]

Adding 1 to a maxed out I32 returns -2147483648, not 0. Which makes sense if you think about how the sign is stored when you convert it to its base2 representation.

[JScherer]

---

@FireFist-Redhawk wrote:

Adding 1 to a maxed out I32 returns -2147483648, not 0. Which makes sense if you think about how the sign is stored when you convert it to its base2 representation.

---

Correct, I apparently forgot how I32's work for a moment. 

My question should ask "Why does it not roll over to min(I32) (-2147483648) as would be expected by other I32 values."

[GerdW · Accepted solution]

Hi J,

---

@JScherer wrote:

---

My question should ask "Why does it not roll over to min(I32) (-2147483648) as would be expected by other I32 values."

---

I guess this was a design decision with the very first LabVIEW version. The iterator of a loop is most probably used to index array elements: it doesn't make sense to index elements with large negative indices!

(At that time LabVIEW on FPGA was no topic at all and this problems mostly is notable on FPGA while loops - as written in the linked KB article.)

[altenbach · Accepted solution]

Rollover would be quite unexpected. Would not like that. There are also other limit, for example the max array size is I32, so autoindexing on a loop with more than ~2^31 iterations is not possible anyway.

Of course you can maintain your own [i] of any datatype by just incrementing a shift register. Dirt cheap!

Ideally, we should be able to define the datatype of loops, see also my old post from 2006! Of course that's not an easy change because it needs very dramatic changes in so many areas (64 bit array sizes, etc.)

QUOTE:

"We need to be able to set the data type for the FOR loop ([N] and [i]): If I wire a U64 to [N], I want [i] to be U64 so it can exceed the range of I32."

[JScherer]

Understood, I hadn't thought about that being a problem for auto indexing

As you all guessed, I found this out for myself the hard way on an FPGA on a loop that executed every 10us for 5.7hr of runtime. I'm now using a U64 so If I have the problem in 5.7M years, I'll let y'all know.

[Intaris]

You could also use a 48-bit counter and let a DSP do the work for you. Should keep you going for more than 80 years. Pretty sure it won't be your problem any more by the time it rolls over. Just leave a note in the source code.... 😉

https://www.xilinx.com/support/documentation/ip_documentation/counter_binary/v12_0/pg121-c-counter-b...

Should be on the palettes, it also has a programmable "reset" which allows for a +1 counter for any arbitrary rollover value.

[natasftw]

---

@JScherer wrote:

My question should ask "Why does it not roll over to min(I32) (-2147483648) as would be expected by other I32 values.

---

https://zone.ni.com/reference/en-XX/help/371361R-01/glang/while_loop/

This won't answer the why.  But it will tell you the behavior is expected/designed.

Would rolling over have provided you with better behavior?  I'm curious what you're using it for that wouldn't have been in an awkward state with the rollover.

[JScherer]

---

@natasftw wrote:

---

@JScherer wrote:

My question should ask "Why does it not roll over to min(I32) (-2147483648) as would be expected by other I32 values.

---

https://zone.ni.com/reference/en-XX/help/371361R-01/glang/while_loop/

This won't answer the why.  But it will tell you the behavior is expected/designed.

Would rolling over have provided you with better behavior?  I'm curious what you're using it for that wouldn't have been in an awkward state with the rollover.

---

For me, I was using the quotient and remainder function with inputs of [counter value] and [constant n] to send data to the host every n loops. As such, rolling over would have been the expected/preferred behavior. 

[rolfk]

---

@JScherer wrote:

---

---

For me, I was using the quotient and remainder function with inputs of [counter value] and [constant n] to send data to the host every n loops. As such, rolling over would have been the expected/preferred behavior. 

---

Except of a disruption at the roll over moment if your divider was not a power of 2! I usually use unsigned integers and subtraction/addition for such things. That has a well defined roll over semantic for all intervals you can use and is usually what you want in that case.

Also under FPGA the increment and decrement node let you configure if it should saturate or roll over. I use both regularly.