On 21/06/14 05:47 PM, Tony Arcieri wrote: > On Sat, Jun 21, 2014 at 2:42 PM, Daniel Micay <[email protected] > <mailto:[email protected]>> 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
