<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jun 21, 2014 at 2:42 PM, Daniel Micay <span dir="ltr"><<a href="mailto:danielmicay@gmail.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=danielmicay@gmail.com&cc=&bcc=&su=&body=','_blank');return false;">danielmicay@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">ARM and x86_64 aren't going anywhere and it's too late for trap on<br></div>
overflow to be part of the baseline instruction set. It's far from a<br>
sure thing that it would even be added.</blockquote><div><br></div><div>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.</div>

<div><br></div><div>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!</div>

<div><br></div><div>If that ever happened, what Rust provides as a baseline today would be obsolete and broken. In the distant future. But still...</div></div><div><br></div>-- <br>Tony Arcieri<br>
</div></div>