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

Kaz Kylheku <kaz@kylheku.com>
Wed, 8 Jan 2014 18:21:15 +0000 (UTC)

          From comp.compilers

Related articles
Implementation dependent behaviour (WAS: Re: Programming language and martin@gkc.org.uk (Martin Ward) (2013-11-20)
Re: Implementation dependent behaviour (WAS: Re: Programming language Pidgeot18@verizon.net (=?UTF-8?B?Sm9zaHVhIENyYW5tZXIg8J+Qpw==?=) (2013-11-23)
Re: Implementation dependent behaviour (WAS: Re: Programming language gah@ugcs.caltech.edu (glen herrmannsfeldt) (2013-11-24)
Re: Implementation dependent behaviour (WAS: Re: Programming language kaz@kylheku.com (Kaz Kylheku) (2013-12-17)
Re: Implementation dependent behaviour (WAS: Re: Programming language martin@gkc.org.uk (Martin Ward) (2014-01-06)
Re: Implementation dependent behaviour (WAS: Re: Programming language martin@gkc.org.uk (Martin Ward) (2014-01-06)
Re: Implementation dependent behaviour (WAS: Re: Programming language ivan@ootbcomp.com (Ivan Godard) (2014-01-08)
Re: Implementation dependent behaviour (WAS: Re: Programming language kaz@kylheku.com (Kaz Kylheku) (2014-01-08)
Re: Implementation dependent behaviour (WAS: Re: Programming language ivan@ootbcomp.com (Ivan Godard) (2014-01-10)
Re: Implementation dependent behaviour (WAS: Re: Programming language gah@ugcs.caltech.edu (glen herrmannsfeldt) (2014-01-10)
Re: Implementation dependent behaviour (WAS: Re: Programming language ivan@ootbcomp.com (Ivan Godard) (2014-01-13)
Re: Implementation dependent behaviour (WAS: Re: Programming language anton@mips.complang.tuwien.ac.at (2014-01-14)
| List of all articles for this month |

From: Kaz Kylheku <kaz@kylheku.com>
Newsgroups: comp.compilers
Date: Wed, 8 Jan 2014 18:21:15 +0000 (UTC)
Organization: Aioe.org NNTP Server
References: 13-11-025 14-01-007
Keywords: C, standards, architecture
Posted-Date: 10 Jan 2014 10:29:19 EST

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


Post a followup to this message

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