Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #1075

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

Show key headers only | View raw

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

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Martin Ward <martin@gkc.org.uk> - 2013-11-20 10:29 +0000
  Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Joshua Cranmer 🐧 <Pidgeot18@verizon.net> - 2013-11-23 01:06 -0600
    Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2013-11-24 21:51 +0000
    Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Martin Ward <martin@gkc.org.uk> - 2014-01-06 19:23 +0000
  Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Kaz Kylheku <kaz@kylheku.com> - 2013-12-17 23:07 +0000
    Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Martin Ward <martin@gkc.org.uk> - 2014-01-06 19:32 +0000
  Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Ivan Godard <ivan@ootbcomp.com> - 2014-01-08 09:02 -0800
    Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Kaz Kylheku <kaz@kylheku.com> - 2014-01-08 18:21 +0000
      Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Ivan Godard <ivan@ootbcomp.com> - 2014-01-10 09:11 -0800
      Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-01-10 23:08 +0000
        Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) Ivan Godard <ivan@ootbcomp.com> - 2014-01-13 12:47 -0800
        Re: Implementation dependent behaviour (WAS: Re: Programming language and IDE design) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-14 14:16 +0000

csiph-web