In the draft standard, as amended by my latest proposal, there are five SPECIFIED modes of arithmetic (in alphabetic order): native, standard, standard-binary, standard-decimal-b, and standard-decimal-d. |
The implementor IS FREE to make "ARITHMETIC IS NATIVE" synonymous with ANY of the standards-specified ones (we disparage "standard" as obsolete, and we disparage "standard-binary" as being problemattical for COBOL's fundamentally-decimal orientation, but we encourage implementor support of the two standard-decimal modes, primarily as an alternative to, rather than as synonymous with, "native"). Making "native" synonymous with one of the standard-decimal modes would not even be an "implementor-defined extension" in my view. But if he did that, this might create problems for users if their programs were successfully running on a different architecture and were being migrated to a platform with that orientation in its COBOL environment.
The implementor is ALSO FREE to add any modes of arithmetic he chooses, and any data-declaration types he chooses, as implementor extensions.
Based solely on what I've seen in this thread, I'm going to use what I gather about recent IBM platforms as an example. If I've deduced right, this architecture is capable of making use of the IEEE decimal floats using decimal encoding directlly in hardware, and is also built to handle the descendants of the old IBM System/360 instruction set directly in hardware or through efficient simulation. I'm also going to assume that other implementations have done similarly, or are planning to do similarly, maybe using the decimal encoding, maybe the binary.
If, say, IBM chooses to make "native" synonymous with "standard-decimal-d", that's fine. What I would hope is that if they did that, they'd provide a "compatibility mode" using similar specification s -- e.g., "ARITHMETIC IS IBM-360". Independent of that, they'd probably also support such hardware-specific USAGE clauses as COMP-4 (with or without "ibm-360 arithmeetic". Programs producing the expected results on the original system would produce exactly the same results in "compatibility mode" on the new. Additionally, IBM would certainly be free to add features to its IEEE-754-oriented COBOL compilers to ease migration from competitive machines -- "ARITHMETIC IS UNISYS-ASERIES", "ARITHMETIC IS HONEYWELL-200", etc., etc.
For such a specification, all the rules for those extensions are implementor-defined. Responsibility for ensuring that the results are the same on the original machine and the new, under those arithmetic mode extensiions lies with the implementor. If they can get away with using the arithmetic of standard-decimal-d without compromising the arithmetic results for any of these "alternative" architectures, they might not even need an arithmetic-compatibility extension.
Whatever the implementor decides to do to handle compatibility with existing programs on competitive or predecessor machines is up to the implementor.