 |
lua-l archive |
|
|
||
|
On Jun 12, 2014 7:49 PM, "Tim Hill" <drtimhill@gmail.com> wrote:
>
>
> On Jun 12, 2014, at 4:24 PM, Jay Carlson <nop@nop.com> wrote:
>
> > Apple's programming language Swift is defined to raise an error on integer overflow:
> > In any case, it's a notable exception in language design to "ints shall behave like C"--whatever that really means, anyway. :-)
> It’s less “ints behave like C” than “ints follow the behavior of the underlying hardware”, which these days almost always means 2’s complement with overflow.
It's pretty circular at this point. Mainstream processors after (say) the i286 are designed to run C code as fast as possible. But what is mainstream? Things you can port your existing C code to....
Anyway, the existing Lua behavior looks like saturation. Unlike C, no Lua code depends on undeclared, benign wraparound yet.
Jay
[historical interest only: I'm not sure what effects an increased interest in runtime bounds checking may have on architecture. ISAs are still toting around luggage from last time, when people were trying to support Ada.
MIPS assembly programmers learn to spell "add" as "addu", because nobody ever uses the trapping signed "add" instruction.
I found a computer organization course handout which emphasized that it was important to treat pointer arithmetic as unsigned. If an array starts at 0x7FFF_FFFE, offset 4 is at 0x8000_0002; therefore the non-trapping "addu" MIPS instruction must be used to generate addresses. But on MIPS, unprivileged code is limited to the address space 0x0-0x7FFF_FFFF and will segfault on access to 0x8000_0000-0xFFFF_FFFF. I can't think of a reason for kernel code to have a single object spanning across the regions. In C, you can't manipulate pointers past the end of objects, so it would seem reasonable to use trapping arithmetic in the general case...I think.
The gcc mips back end apparently does not emit "add" or "sub" even in -ftrapv mode; it generates calls to __addv?i3 helpers in libgcc instead.]