A bit of background on compilers exploiting signed overflow
There&#x27;s been a lot of discussion about undefined behavior on HN recently, and I&#x27;m gradually starting to question if the conventional approach to compilers might be a giant dead-end. In this case, our conventional languages provide no way for a programmer to say &quot;I care about overflow&quot;. Because face it, the vast majority of programs a compiler sees are written extremely sloppily. Most of the time there&#x27;s this huge disconnect between the amount of effort the programmer and the ghost of the compiler writer are putting into considering such situations.<p>Now, most of the time this disconnect is a good thing. Division of labor ensures that the work of the compiler writer is amortized across many many programmers. But the discussion around undefined behavior is a sign that the load on the compiler writer has gotten too onerous, to the point that everybody is paying a cost (in reduced performance, in increased compiler complexity leading to reduced compiler stability, in compilers antagonistically interpreting standards like lawyers) for a level of correctness along one narrow dimension that only a tiny fraction of users actually care about.<p>What if we instead said, &quot;compilers will never ever consider overflow&quot; and let those who care about overflow fend for themselves in the source language? Among other things that would allow integers to always be the word size of the computer they&#x27;re running on.<p>(My interest in these questions stems from trying to program in an idealized assembly language for the past year: <a href="http:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;mu" rel="nofollow">http:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;mu</a>. After writing 10kLoC of assembly to build a simple text editor (<a href="http:&#x2F;&#x2F;akkartik.name&#x2F;post&#x2F;mu" rel="nofollow">http:&#x2F;&#x2F;akkartik.name&#x2F;post&#x2F;mu</a>) I&#x27;m surprised to find it quite ergonomic. High level languages today seem to provide three kinds of benefits over traditional&#x2F;ugly assembly: expressiveness (e.g. nested expressions, classes), safety (e.g. type checking) and automation (e.g. garbage collection). An idealized assembly language gives up some expressiveness, but doesn&#x27;t seem to affect the other benefits. As such, it&#x27;s at an extreme end of the trade-off I describe. I&#x27;m hoping my experience will largely translate even when Mu eventually implements a high-level language.)<p><i>Edit 21 minutes later</i>: For reference, here&#x27;s how I&#x27;ve been thinking about undefined behavior while building Mu: <a href="https:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;mu&#x2F;blob&#x2F;5dd82a8a70&#x2F;001help.cc#L40" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;akkartik&#x2F;mu&#x2F;blob&#x2F;5dd82a8a70&#x2F;001help.cc#L4...</a>. Comments most welcome.