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

On 2014-01-08, Ivan Godard <ivan@ootbcomp.com> wrote:
> 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.
>
> 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.


It's only undefined on paper. In reality, if you don't make it wrap in C like
in Java, unknown numbers of C programs will break, and not all of them doing it
by accident.


> 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.


This kind of thing is quite useful for optimizing certain code. For instance,
fixed-point implementations of codecs, in which reproducing bit-exact results
over the test vectors requires "saturation" treatment of overflow. Clamping
the results in software adds many additional cycles.


--
Music DIY Mailing List: http://www.kylheku.com/diy
ADA MP-1 Mailing List: http://www.kylheku.com/mp1

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