<br style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><br><div class="gmail_quote">On Tue, Jun 4, 2013 at 7:35 AM, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 3/06/2013, at 6:58 PM, Carter Schonwald wrote:<br>
> If the Int type had either of these semantics by default, many many performance sensitive libraries would suddenly have substantially less compelling performance. Every single operation that was branchless before would have a branch *every* operation..... this would be BAD.<br>
<br>
</div>Actually, the x86 can be configured to trap integer overflows,<br>
so on that not entirely unpopular platform, there need be NO<br>
extra branches.<br></blockquote><div><br>Well yes and no. See <a href="http://software.intel.com/en-us/forums/topic/306156">http://software.intel.com/en-us/forums/topic/306156</a><br>Using instructions like cmovo "Conditional MOve on Overflow" we can test without a branch -- so in that sense yes.<br>
<br>No, because the use of the word 'trap' is a bit misleading. If we understand 'trap' as synchronous interrupt, then intel provides the infrastructure to literally trap floating point errors but for integers such a 'trap' only works if the instruction stream contains instructions like INTO or CMOVO etc.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Alternatively, and more portably, there could be separate<br>
Int and UnsafeInt types, and the performance sensitive libraries<br>
could be rewritten to use UnsafeInt.<br>
<br>
For just one week, I had the joy of using a C compiler where<br>
signed integer overflow was trapped. It was *wonderful*.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote></div><br>In Discipline of Programming (in 1976!) Dijkstra exactly described this problem, and squarely put the blame on poorly engineered machines.<br>He introduced 3 concepts/terms:<br>
UM : unbounded machine<br>SLM : sufficiently large machine<br>HSLM : hopefully sufficiently large machine<br><br>The UM -- like a Turing machine -- has no messy restrictions of finiteness like wordsize and is therefore pleasant to reason with and impossible to physically build.<br>
<br>The SLM is like most of our actual machines -- actual finite state machines approximating our conceptually nice unbounded machines. The problem is when the approximation fails, the SLM behaves unpredictably.<br><br>So we have the HSLM, which (I quote): <br>
<blockquote>The HSLM is two things merged into one. Besides acting as the largest SLM we can afford, it checks, when called to execute a program, as the computation proceeds, whether this SLM is large enough for the current computation. If so, it proceeds with the simulation of the UM's behaviour, otherwise it refuses to continue.<br>
<br>There exist, regretfully enough,in which the continuous check that the simulation of the behaviour of the UM is not beyond their capacity is so time-consuming, that the check is suppressed for the sake of efficiency.<br>
<br>It is very difficult to use such machines… and we ignore them in the sequel!!<br></blockquote>In short the problem is our machines: if catching errors involves checking and checking involves a cost, some program(ers) will sometimes seek to avoid that.<br>
Moving the check to the hardware -- ie synchronous trap on errors -- removes the cost and the temptation to avoid.<br><br>Until we get such machines, these arguments will continue to be there!<br>