As far as that goes, if an implementor has a native IEEE machine, what the implementor does depends on whether or not he wants the customers of his prior machines to be able to continue to run their programs on the new system without change in behavior or results. |
It is a simple matter for the vendor to "suggest" to his users that they use, say, ARITHMETIC IS STANDARD-DECIMAL explicitly in their new programs, for most accurate results and greatest efficiency on the "latest and greatest" system, and provide support for predecessor platforms under the native arithmetic mode. That actually makes the most sense.
But by changing what "ARITHMETIC IS NATIVE" meant (either explicitly stated or by default), the vendor would be shooting himself in the foot for any existing programs that weren't expecting decimal128 (or binary128) intermediate data items in arithmetic. In addition, he'd need to add his OWN mode of arithmetic (e.g., ARITHMETIC IS PHILCO-2000 or ARITHMETIC IS IBM-7080) as an implementor-defined extension to standard COBOL to provide for what used to be "native" meant on predecessor platforms. Users of preexisting programs would thus have to specify one of these modes of arithmetic.
Changing the DEFAULT behavior to a mode other than "NATIVE", and requiring "ARITHMETIC IS NATIVE" be added to old programs , is contrary to what "native" actually is. The implementor COULD get away with it in theory, but that too would be an implementor-defined extension to standard COBOL.
Date: Thu, 24 Feb 2011 10:47:05 -0700
Subject: Re: Two technical questions on IEEE Std 754-2008
CC: forieee@xxxxxxxxxxxxxx; stds-754@xxxxxxxxxxxxxxxxx
"We can't tell vendors that the "native arithmetic" they've been using for fifty years has to be CHANGED to conform to IEEE Std 754-2008. "
*sigh* you don't have to tell them that. you assert that if someone has a native IEEE machine, that they use native.
If the system has IEEE and nonIEEE modes (e.g. IBM zSeries) then it's up to the vendor to provide a switch.
The point is don't bake more into the language standard than you need to at this juncture. FCD already in progress, it's too late procedurally and practically to do it well.