From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org  Fri Jan 18 08:00:37 2013
Return-Path: <owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org>
X-Original-To: sc22wg5-dom8
Delivered-To: sc22wg5-dom8@www.open-std.org
Received: by www.open-std.org (Postfix, from userid 521)
	id EDC27356CAC; Fri, 18 Jan 2013 08:00:36 +0100 (CET)
Delivered-To: sc22wg5@open-std.org
Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10])
	by www.open-std.org (Postfix) with ESMTP id 3B62B356CA6
	for <sc22wg5@open-std.org>; Fri, 18 Jan 2013 08:00:34 +0100 (CET)
Received: from Maru6 (218-42-159-105.cust.bit-drive.ne.jp [218.42.159.105])
	(authenticated bits=0)
	by nag-j.co.jp (8.14.5/8.14.5) with ESMTP id r0I51te5063310
	for <sc22wg5@open-std.org>; Fri, 18 Jan 2013 05:02:00 GMT
	(envelope-from malcolm@nag-j.co.jp)
Message-ID: <D061B7F749984EA7BFC4CD74DDCDFA47@Maru6>
From: "Malcolm Cohen" <malcolm@nag-j.co.jp>
To: "WG5" <sc22wg5@open-std.org>
References: <20130108205438.50F4E356B56@www.open-std.org><20130113210632.B1C67356BEA@www.open-std.org><20130116050422.92E30356BE0@www.open-std.org><20130116191114.A6A75356A2B@www.open-std.org><!&!AAAAAAAAAAAYAAAAAAAAAIW2PXiCpJ1HvrNfXE1xaemi1wAAEAAAAOOru+gTP09CtEvym9nKWdsBAAAAAA==@ctdedo.com> <CAHSokPy8G2w0DZPoztk4LE47X_77zaS0duuR_3vyg3N7tQ9bcg@mail.gmail.com>
In-Reply-To: <CAHSokPy8G2w0DZPoztk4LE47X_77zaS0duuR_3vyg3N7tQ9bcg@mail.gmail.com>
Subject: Re: (j3.2006) (SC22WG5.4899) [ukfortran] Comment on a comment on the WG5 letterballot on N1947
Date: Fri, 18 Jan 2013 14:01:56 +0900
Organization: =?utf-8?B?5pel5pysTkFH?=
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="utf-8";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 15.4.3555.308
X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

Keith Bierman wrote:
>OpenVMS, as far as I know, has only run on processors which physical support 
>for overflow detection (Alpha, VAX). So this is not a very useful proof point 
>for the significant number of processors that do not have such hardware 
>support.

The vast majority of processors, including the x86 family, have such hardware 
support.

>>        2.  Detection of integer overflow conditions was part of John Reid's 
>> ENABLE block
>>proposal in 1994.
>
>John was proposing a language feature;
> he didn't have the burden of actually implementing it,
> so again this example
>proves nothing germane to Bill's objections.

John's ENABLE block was not shot down by people raising objections to integer 
overflow detection.

>Look at current GPU architecture manuals and hardware specifications for 
>examples of compute engines for which such handling could prove quite costly 
>(indeed, making moving computation off the CPU possibly pointless). GPUs are 
>similar (in many ways) to the old FPS style array processors and Cray style 
>vector machines (just not nearly as polished or easy to program).
>
>I'm not saying that these aren't useful or interesting language features. But 
>those without any "skin the game" w.r.t. >implementing either the hardware or 
>software should not blithely ignore the costs proposed.

(1) No-one is blithely ignoring anything.
(2) I do in fact know what it costs in hardware and software; in hardware the 
costs are not zero but they are miniscule compared to many other cute features 
that are being implemented.
(3) I have in fact implemented it in software without using the hardware 
support.

Or the snarkier but more amusing:

"Losing a rocket on the launch pad: a few billion dollars.
Being able to brag about your GPU: priceless."

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo. 

