Re: [ANN] Lua 5.3.0 (work1) now available

[Jay Carlson <nop@...>]

On Jul 6, 2013, at 4:59 AM, liam mail wrote:

> On 6 July 2013 09:38, Miles Bader <miles@gnu.org> wrote:
> liam mail <liam.list@googlemail.com> writes:
> > "In case of overflows in integer arithmetic, all operations wrap around,
> > according to the usual rules of two-complement arithmetic."
> >
> > Usual rules of two complement arithmetic? Would some care to explain as in
> > C signed ints do not wrap.

Worse: signed int overflow results in undefined behavior, and ever since the Morris Worm we are all-too-familiar with how broad C's "undefined behavior" is.

> Well to be fair, it doesn't say "C signed ints," and the behavior of
> twos-complement signed values are clear enough...
> 
> People who are more than casually interested in computers should have at
> least some idea of what the underlying hardware is like.  Otherwise the
> programs they write will be pretty weird.  -- Donald Knuth

They should have at least some knowledge of what the compiler is like too. In this case, the compiler has license to assume programs do not overflow and the compiler may produce optimizations with that knowledge.

I don't think gcc will "mis-compile" the core Lua VM in this case; the examples I know of involve partial evaluation. 

> The code is written in C so this is why I am asking what the usual rules are as that specific operation in C is undefined, hence it is not normal. So if you would not mind explaining what the normal operation is and point me to where Lua's C code detects this illegal overflow and prevents it before the undefined behaviour happens that would be so kind and more constructive.

Let's back up a minute. Who actually *wants* the two's-complement overflow behavior? There are some bit-twiddling algorithms which depend on it, but Lua bit-twiddling is shunted off into a separate module. 

At the assembly level, there is pressure for addition of MAX_INT and 1 to result in *some* deterministic bit pattern in the destination register. But we're about three layers of abstraction up from that. On target hardware without hardware floating point, going from softfp to some kind of int is a huge speedup, and explicit int overflow checks are likely to be tiny in comparison. My intuition is that VM costs will swamp the cost of checks (certainly on MIPS). If the cost of detecting signed integer overflow is acceptable, we can choose the behavior we want. And "wraps to negative" just seems much worse for Lua programs than "cast to nearest double" or exception-raising.

Jay