Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design)

On 11/20/2013 2:29 AM, Martin Ward wrote:


<snip>


> (2) CPU designers may choose to implement that behaviour in hardware
> on the next iteration of the CPU. Now the programs run fast on *all*
> CPUs.
>
> Everybody wins.
>
> -- Martin


I am such a CPU designer. We faced the "undefined" issue in our Mill
family of general-purpose CPUs (ootbcomp.com). Not only are languages
under-constraining, they are also sometimes over-constraining: signed
integer overflow is undefined in C but required to wrap in Java.


Our solution was to offer four hardware "overflow-behavior" options for
every operation for which overflow is possible: modulo (wraparound),
excepting, saturating, and double-width result (which cannot overflow).
It is up to the compiler to choose the behavior to match the desired or
mandated semantics. The other behaviors are also available via intrinsics.


We also have a tool-chain option to force all non-explicit overflow
behaviors to excepting throughout the program. It is truly astonishing
how often "working" programs experience unanticipated (and previously
unknown) overflow. For some value of "working".


Ivan

Return to the comp.compilers page.
Search the comp.compilers archives again.