[rust-dev] Integer overflow, round -2147483648

Daniel Micay danielmicay at gmail.com
Sat Jun 21 15:02:05 PDT 2014

On 21/06/14 05:47 PM, Tony Arcieri wrote:
> On Sat, Jun 21, 2014 at 2:42 PM, Daniel Micay <danielmicay at gmail.com
> <mailto:danielmicay at gmail.com>> wrote:
>     ARM and x86_64 aren't going anywhere and it's too late for trap on
>     overflow to be part of the baseline instruction set. It's far from a
>     sure thing that it would even be added.
> Having watched the debacle that was Azul trying to get features added to
> Intel CPUs, like hardware transactional memory or realtime zeroing into
> L1 cache, I strongly agree. We can't assume anything about the hardware
> manufacturers will do, they just don't care about this stuff, and their
> roadmaps for adding anything like this are terrible at best.
> But here's a hypothetical situation: it's 202X and after much ado Intel,
> ARM, AMD, and others have just rolled out some new CPU instructions and
> fancy new ALU with fast overflow detection in hardware. Overflow
> detection is fast now!
> If that ever happened, what Rust provides as a baseline today would be
> obsolete and broken. In the distant future. But still...

It's not possible to add new instructions to x86_64 that are not large
and hard to decode. It's too late, nothing short of breaking backwards
compatibility by introducing a new architecture will provide trapping on
overflow without a performance hit. To repeat what I said elsewhere,
Rust's baseline would still be obsolete if it failed on overflow because
there's no indication that we can sanely / portably implement failure on
overflow via trapping. It's certainly not possible in LLVM right now.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140621/2c7647a9/attachment.sig>

More information about the Rust-dev mailing list