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

Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2014-01-08, Ivan Godard <ivan@ootbcomp.com> wrote:


(snip)
>> 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.


Well, C has unsigned with defined wrap on overflow. C still allows for
ones complement or sign magnitude along with the more usual twos
complement. As I understand it, Unisys still sells some ones
complement machines. I am still waiting for a C compiler for the 7090
to test out sign magnitude in C.


Java doesn't have the unsigned types, except for 16 bit char. Some
that might have been done unsigned in C, can be done with that
appropriate wrap of twos complement 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 has been hardware tradition for a long time to offer double width
product on multiply and dividend on divide, but rare for high-level
languages to allow for its use.


I believe that gcc recognizes casts to (long long) on the operands of
multiply to generate a single multiply instruction with a double
length product. (That is, it doesn't do the three multiplies by zero
that the casts imply.) I don't know about divide.


I have at times needed to multiply two 32 bit values, for a 64 bit
product, then divide by another 32 bit value. I sometimes hope that
the compiler figures it out.


(snip)


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


I have also worked on some dynamic programming algorithms that require
saturating arithmetic. I believe that Intel SSE allows for it, but it
is rare for normal CPU instructions.


-- glen

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