ISO/IEC JTC1/SC22/WG5 N1592 Repository of Requirements Version of 19 April 2004 (WG5 Standing Document 5 - supersedes N1189) This standing document is the vehicle by which WG5 manages the specification of requirements for future revisions of the Fortran standard. It is a working document of WG5. The Status: field is one of the following: For Consideration, Being Investigated, Accepted, Accepted with changes, Not accepted for the next revision, Rejected (reasons must be given), Being Developed. Status must not change from Accepted to Being Developed until the Specification field is complete. This field contains all relevant material for the chosen development body. If the status is Being Developed, an additional field is supplied: Target Date for Completion. When a proposed revision is adopted as a standard, Standing Document 5 is frozen and a new repository is started. Items are transferred to the new repository only if requested by a member body or if so decided by WG5. ------------------- Contents of Repository 04-001 Co-array Fortran for parallel programming 04-002 Decimal floating point arithmetic 04-003 Conformance to IEEE 754R 04-004 KIND environment specification ------------------- Number: 04-001 Title: Co-array Fortran for parallel programming Submitted By: UK Status: For Consideration References: ISO/IEC JTC1/SC22/WG5 N1317 Basic Functionality: Co-Array Fortran (CAF) is a simple parallel extension. It assumes the SPMD programming model with the program, both text and data, replicated a fixed number of times. Each copy is called an image. Normal subscripts refer to memory addresses within an image while a second set of subscripts refer to memory addresses in other images. Each image executes asynchronously with explicit synchronization provided by the programmer. For example, the statement real, dimension(n)[*] :: x,y declares that each image has two real arrays of size n. When an image executes the statement x(:) = y(:)[q] it makes a copy of the array y from the memory of image q into array x in the memory of the image executing the statement. A reference to x or y without its second set of subscripts is a reference to the local array. Rationale: Fortran 95 included language features needed by HPF in the expectation that HPF would become widely used for parallel programming, but unfortunately this has not happened. The reason is probably that HPF's performance in practice is often disappointing. Instead MPI has become the de-facto standard for parallel programming. This is awkward to program and the performance tends to decay as the number of processes increases. MPI is essentially a library of C procedures. In contrast, CAF involves additional syntax that requires support in the compiler. The lack of any external library call, coupled with the fact fact that CAF has been designed to be easy to support by compiler writers, gives great scope for communications optimization compared to MPI-based codes. It is our belief that the wide adoption of CAF would lead to easier program development, faster execution, and better maintainability, particularly where the number of processes is large. Estimated Impact: Other features would be little affected since execution is normal and normal optimizations are applicable except where there is explicit CAF syntax. Uniprocessors would be required to recognize the syntax but can ignore most of it and, if asked, would indicate that the number of images is one. Detailed Specification: See report RAL-TR-1998-060 which is an updated version of N1317 and is available as ftp://ftp.numerical.rl.ac.uk/pub/reports/nrRAL98060.ps.gz Fortran 2003 uses brackets for array constructors, which does not conflict with brackets indicating a co-array reference though it does mean that such a reference will not be as obvious as it was with Fortran 95. We recommend allowing co-arrays to be of a type that has allocatable components. History: Presented by John Reid at the 1998 meeting of WG5 in Trollhattan. ------------------------------------------------------------------------ - Number: 04-002 Title: Decimal floating point arithmetic Submitted By: UK Status: For Consideration References: 1. A Summary of Densely Packed Decimal encoding http://www2.hursley.ibm.com/decimal/DPDecimal.html 2. Draft changes to the C language for decimal arithmetic WG14-N1016 http://std.dkuug.dk/JTC1/SC22/WG14/www/documents Basic Functionality: To allow for decimal floating point arithmetic Rationale: Languages increasingly support decimal arithmetic in addition to binary or hexadecimal arithmetic, e.g. C#, COBOL, Visual Basic. Now that IBM are about to sell hardware with packed decimal floating point, C and C++ are preparing TRs to extend those languages to provide decimal floating-point facilities, principally for financial applications. In order to retain competitiveness and to maintain interoperability with C, Fortran should adopt comparable facilities. Estimated Impact: no effect on existing programs Detailed Specification: Current hardware developments give a form of packed decimal holding three decimal digits in ten bits. However this proposal for Fortran does not depend on the hardware format and allows for the possibility that within a single program unit some real variables may be held and operated upon in decimal form and some in binary or hexadecimal (or other radix) form, and that the default radix for the processor may be any of these. History: ------------------------------------------------------------------------ - Number: 04-003 Title: Conformance to IEEE 754R (IEEE Standard for Floating-Point Arithmetic) Submitted By: UK Status: For Consideration References: 1. IEEE 754R-200x (IEEE Standard for Floating-Point Arithmetic) This is still being developed. The March 2004 document is at http://www.validlab.com/754R/drafts/754r.pdf 2. Draft changes to the C language for decimal arithmetic WG14-N1016 http://std.dkuug.dk/JTC1/SC22/WG14/www/documents Basic Functionality: To allow for decimal floating point arithmetic in conformance with IEEE 754R Rationale: Other languages, notably C and C++, are being extended to accommodate features of IEEE 754R, principally for decimal floating point arithmetic. In order to retain interoperability with C, Fortran should adopt comparable facilities. Estimated Impact: no effect on existing programs Detailed Specification: This proposal is dependent on facilities to specify decimal arithmetic being adopted separately. It is necessarily an outline specification as IEEE 754R is not yet complete. 1. Add reference to IEEE 754R in section 1.9. 2. Add new intrinsic procedures as required by IEEE 754R section 5 (Operations) and Appendix L (Language extensions) to section 14 of the Fortran base language. Depending on details in the final form of IEEE 754R, some procedures may be added to section 13. References to the term "IEEE arithmetic", which occur mainly in section 14 but also in sections 7, 13 and 15, may need to be redefined. History: ------------------------------------------------------------------------ - Number: 04-004 Title: KIND environment specification Submitted By: UK Status: For Consideration References: Basic Functionality: Provide prespecified parameter arrays in FORTRAN_ENV that define the number (size of array) and available kind values for each intrinsic type. Rationale: For many programs it would be useful if it were possible to find the number of different kinds available for the intrinsic types and the actual kind values assigned by the processor. Estimated Impact: Little or no effect on existing programs Detailed Specification: I would expect there to be declarations like the following defined in ISO_FORTRAN_ENV INTEGER,PARAMETER:: FP_KINDS(3) = (/4,8,16/), & INT_KINDS(2) = (/4,2/), & CHAR_KINDS(1)= (/1/)... An additional requirement would be that FP_KINDS(1) must be the value for KIND(0.0E0) and FP_KINDS(2) that of KIND(0.0D0). Similarly the first element in each array must contain the kind value for the default intrinsic type. An inquiry as to the SIZE(FP_KINDS) will return the information as to the number of floating point, etc. representation methods available. History: