Re: [PATCH] Loop Overflow Bug Fix

[Coda Highland <chighland@...>]

On Mon, Nov 20, 2017 at 1:58 PM, Paige DePol <lual@serfnet.org> wrote:
> Coda Highland <chighland@gmail.com> wrote:
>
>> On Sun, Nov 19, 2017 at 12:13 AM, KHMan <keinhong@gmail.com> wrote:
>>> Keeping 2s complement arithmetic in looping and its flaw(s) isn't
>>> perfect but it's a known quantity. Patching the looping code would make it
>>> "2s complement but not quite 2s complement". Either way, I hope we can have
>>> some updates to the section on numerical loops in the reference manual.
>>
>> It's NOT 2s complement, though. It's 2s complement if you're working
>> with integer loops, but it's signed magnitude if you're working with
>> floating point, and Lua doesn't tell you explicitly which you're
>> working with unless you ask. So it's already "signed magnitude, except
>> when it's 2s complement" and Paige's patch brings it just a little bit
>> closer to "always signed magnitude".
>>
>> /s/ Adam
>
> Okay, maybe you can help answer my question Adam... how does my patch
> change the representation of the numbers from being 2s complement for
> integer based loops?
>
> From what I have read on Wikipedia, which matches what I remember from
> my Comp-Sci classes all those years ago, 2s complement is a way that
> most modern processors internally represent integers. How does changing
> the loop logic to prevent an overflow affect this representation?
>
> Thanks for any insight, it is appreciated!
>
> ~Paige
>

I mean, from a technical perspective, it doesn't stop being 2s
complement in the internal representation. But one of the things about
dealing with 2s complement arithmetic is the concept of overflow --
the entire concept of 2s complement only works if you've got fixed
width values that can overflow.

And your patch fixes one of the ways it can overflow, bringing it
closer to the behavior of non-integer loops.

According to the reference manual, for loops already pay attention to
the sign of the step, so you couldn't write a loop that DEPENDS on the
overflow behavior anyway -- if you tried to write "for i = 1, -1,
1000000" in hopes of overflowing the integer and coming back up from
below, it wouldn't work.

So while the internal representation is still 2s complement, the
checks and fixes keep it from ACTING like 2s complement arithmetic.

/s/ Adam