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

[Miles Bader <miles@...>]

2013/7/7 Jay Carlson <nop@nop.com>
> 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.

My point, though, was that it isn't clear without looking at the code
that they used C signed ints in the implementation at all, and the
hand-wringing only applies if they did.

> 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.

I do not know who the intended audience of this feature are...  What's
optimal for bit-twiddlers who care about exact bit representations may
not be perfect for those who simply have slow FP and want something
faster.

The current behavior has the big advantage that it makes the behavior
of integers very predictable:  you know that once something is an
integer, it's likely (you can tell by looking at the program source)
to _stay_ an integer, which can be important if you feed it to a C
library that wants that.

-miles

--
Cat is power.  Cat is peace.