larryw@uw-nsr.UUCP (Larry Weissman) (05/20/89)
The Fortran77 standard went a long way toward making it possible to port and maintain code across a variety of architectures. It may be a bit late, but here is my wish list for Fortran8x. It consists of things which are difficult to do portably because they are not dealt with in the '77 standard. Please keep in mind that I have not seen the proposed '8x standard. ---------------------------------------------------------------------------- OPEN statement options: Standardize LRECL: use bytes or bits, not implementation-defined units. READONLY or the equivalent. Default OPEN at beginning, else an option for OPEN at end. Case insensitivity for CHARACTER options (other than file names). Bitwise intrinsics for any type object: Logical AND, OR, NOT, LSHIFT, RSHIFT. Cyclic (arithmetic) shifts. LOGICAL FUNCTION IFBIT(src,bitoffset) (returns .true. if bit is 1, else .false.) SUBROUTINE SETBIT(src,bitoffset,<1/0> or <.true./.false.>) (sets or clears a bit) Byte-oriented intrinsics: SUBROUTINE MOVBYT(src,srcoffset,dest,destoffset) Offsets must be non-negative. INTEGER FUNCTION IBYTE(src,srcoffset) Return integer value of a byte. (If hardware does not support bytes, then a byte is 8 consecutive bits.) Standard INCLUDE syntax. Prompt standardization (i.e. suppress CR-LF). Call by value (for malloc). CALL EXIT, probably without an argument. It a status value needs to be returned, how about CALL EXITS(value). Both should be available. Standardize unprintable characters for CHARACTER strings (To allow insertion of characters like <escape> in a string at compile-time, ---------------------------------------------------------------- Desirable features: Longer variable and global names. At least 16 characters. ADDRESS type (not necessarily an INTEGER). ADDRESSOF(any object) intrinsic. SIZEOF(any object) intrinsic. Returns length in some standard unit, eg. bits, of any object except a subprogram. Malloc/free (and variants). BYTE type (8-bit integer). Call with subprogram address. (So subprogram names can be stored in common, rather than be passed through an argument list). CHARACTER*(*) FUNCTION TOASCII(string), and FROMASCII(string), to convert strings between ASCII and internal representation. Standardize integer status values for system & library calls. CHARACTER*(*) with PARAMETER, eg.: CHARACTER*(*) HELPFILE PARAMETER (HELPFILE='/usr/myname/help.dat') Minimum limit spec for length for a CHARACTER string. Maybe: DO WHILE block construction. Maybe: Standard DATE, TIMEOFDAY, EXECUTIONTIME. ---------------------------------------------------------------- Desirable compiler features: Subscript checking compiler options. Uninitialized variable checking (like old Waterloo WATFOR/WATFIV). Would only be needed for longer data objects. FLAG_NONSTANDARD - warn about non-standard construction but keep going. Intrinsics for machine constants - like those in cmlib/machdep. Transfers into a loop or block flagged as illegal at compile-time. This would include the "ambiguous" nested loop code discussed at length in comp.lang.fortran. Make '_' or something similar a legal alphabetic character. Documentation features: Require that extensions to standard be highlighted in documentation. Require that deficiencies from standard be documented. Desirable environmental features: Interactive debuggers (for interactive systems). The debugger does not have to be standardized - it only has to exist and be usable from Fortran. Fortran binding for all system calls and standard libraries. -- ----------------------------------------------------------------------------- Larry Weissman Center for Bioengineering WD-12 larryw@nsr.bioeng.washington.edu Univ of Washington, Seattle, WA 98125
acliu@skat.usc.edu (Alejandro Liu) (05/22/89)
In article <1509@uw-nsr.UUCP> larryw@nsr.bioeng.washington.edu (Larry Weissman 5-2011) writes: >The Fortran77 standard went a long way toward making it possible to port >and maintain code across a variety of architectures. It may be a bit late, >but here is my wish list for Fortran8x. It consists of things which are >difficult to do portably because they are not dealt with in the '77 standard. > >Please keep in mind that I have not seen the proposed '8x standard. >---------------------------------------------------------------------------- [A bunch of nice additions deleted] Hmm...Seems to me that you have been programming in C and just switched to Fortran (Or the other way around?). The only things you need to ask for is for recursion, stdio, printf...(All sorts of C stuff...) acliu@skat.usc.edu (Alejandro Liu) (Simple .signature, $CHEAP$)
hirchert@uxe.cso.uiuc.edu (05/22/89)
Larry Weissman (larryw@uw-nsr.UUCP) writes: >The Fortran77 standard went a long way toward making it possible to port >and maintain code across a variety of architectures. It may be a bit late, >but here is my wish list for Fortran8x. It consists of things which are >difficult to do portably because they are not dealt with in the '77 standard. X3J3 has already forwarded a revised draft to X3 for a second public comment period, so it too late to do anything except in response to that public comment. > >Please keep in mind that I have not seen the proposed '8x standard. I will try to point out what is already in the revised draft. >---------------------------------------------------------------------------- >OPEN statement options: > Standardize LRECL: use bytes or bits, not implementation-defined units. Problem attacked in a different way. Units remain processor dependent, but you can inquire how many units a given iolist would require. Note that defining which units are used would not help unless you also knew how big each item was and the effects of overlap/alignment in combining multiple items in an iolist. > READONLY or the equivalent. ACTION='READ' > Default OPEN at beginning, else an option for OPEN at end. POSITION='ASIS', 'REWIND', or 'ATEND'. 'ASIS' means as positioned by the system (and is the default). > Case insensitivity for CHARACTER options (other than file names). Done. >Bitwise intrinsics for any type object: > Logical AND, OR, NOT, LSHIFT, RSHIFT. Cyclic (arithmetic) shifts. > LOGICAL FUNCTION IFBIT(src,bitoffset) > (returns .true. if bit is 1, else .false.) > SUBROUTINE SETBIT(src,bitoffset,<1/0> or <.true./.false.>) > (sets or clears a bit) Bit intrinsics from Mil. Std. 1753 adopted. Different names, but offering the same basic capabilities. >Byte-oriented intrinsics: > SUBROUTINE MOVBYT(src,srcoffset,dest,destoffset) > Offsets must be non-negative. > INTEGER FUNCTION IBYTE(src,srcoffset) > Return integer value of a byte. > (If hardware does not support bytes, then a byte is 8 consecutive bits.) No byte intrinsics distinct from the bit intrinsics. >Standard INCLUDE syntax. From Mil. Std. 1753 again. >Prompt standardization (i.e. suppress CR-LF). Partial record input/output. >Call by value (for malloc). Not done. >CALL EXIT, probably without an argument. It a status value needs to be > returned, how about CALL EXITS(value). Both should be available. Not done. Why would the standards committee want to provide a subroutine to do what the STOP statement does? >Standardize unprintable characters for CHARACTER strings (To allow insertion > of characters like <escape> in a string at compile-time, ACHAR intrinsic allows access to characters by ASCII code value. ACHAR is allowed in constant expressions. >---------------------------------------------------------------- >Desirable features: > Longer variable and global names. At least 16 characters. 31 character names. > ADDRESS type (not necessarily an INTEGER). POINTER attribute, not data type. > ADDRESSOF(any object) intrinsic. Not done as a function, and limited to objects with a TARGET attribute (to avoid trashing optimization) > SIZEOF(any object) intrinsic. Returns length in some standard unit, > eg. bits, of any object except a subprogram. Not done. Not needed for standard storage management. > Malloc/free (and variants). Dynamic storage allocation/deallocation supported, but not through use of the C functions. Allocation sizes given in terms of array elements and/or string lengths for the type, so programmer does not need to know sizes in terms of a standard unit. > BYTE type (8-bit integer). Framework provided for supporting multiple sizes of integers, but an 8-bit integer is not specifically required. > Call with subprogram address. (So subprogram names can be stored in > common, rather than be passed through an argument list). Not done. > CHARACTER*(*) FUNCTION TOASCII(string), and FROMASCII(string), to > convert strings between ASCII and internal representation. Not certain what you mean by this. It sounds like something that is not possible on some machines because of using a character representation too small to hold all possible ASCII code values. On machines where it is possible, you could write such functions using CHAR, ICHAR, ACHAR, and IACHAR. > Standardize integer status values for system & library calls. Not done beyond what was already required in FORTRAN 77. > CHARACTER*(*) with PARAMETER, eg.: > CHARACTER*(*) HELPFILE > PARAMETER (HELPFILE='/usr/myname/help.dat') Already in FORTRAN 77. > Minimum limit spec for length for a CHARACTER string. Not done. > Maybe: DO WHILE block construction. Done. (Mil. Std. 1753, again.) > Maybe: Standard DATE, TIMEOFDAY, EXECUTIONTIME. Standard subroutine to obtain date and time together (to be certain they are "in synch" when obtained near midnight). Execution time attempted but not done because of problems with things like multiprocessors. >---------------------------------------------------------------- >Desirable compiler features: > Subscript checking compiler options. Not done. > Uninitialized variable checking (like old Waterloo WATFOR/WATFIV). > Would only be needed for longer data objects. Not done. > FLAG_NONSTANDARD - warn abouts non-standard construction but keep going. A processor would be required to be able to identify nonstandard usage. It is expected that most vendors would do this in the compiler, but it would be acceptable (as far as the standard is concerned) to do it in a separate program, since the standard looks at the hardware and software system taken as a whole. > Intrinsics for machine constants - like those in cmlib/machdep. I don't know what's in cmlib/machdep, but Fortran 8x has a number of "environmental inquiry" intrinsics, especially for floating point. > Transfers into a loop or block flagged as illegal at compile-time. > This would include the "ambiguous" nested loop code discussed > at length in comp.lang.fortran. This should be covered by the requirement to be able to identify nonstandard usage, but whether it is depends on how this requirement was formulated in the draft and I don't have my copy here to check. > Make '_' or something similar a legal alphabetic character. Done. > >Documentation features: > Require that extensions to standard be highlighted in documentation. Not done. The standard has no concept of processor documentation. > Require that deficiencies from standard be documented. Not done. If the processor has deficiencies with respect to the standard, it is not standard conforming. Trying to say that if it does not document these deficiencies, it's not standard conforming is a bit of a non sequitur. > >Desirable environmental features: > Interactive debuggers (for interactive systems). The debugger does > not have to be standardized - it only has to exist and be > usable from Fortran. Not done. > Fortran binding for all system calls and standard libraries. This is being done by other committees for certain specific operating system environments (e.g., POSIX), but doing one for all possible operating systems doesn't seem practical. >-- >----------------------------------------------------------------------------- >Larry Weissman Center for Bioengineering WD-12 >larryw@nsr.bioeng.washington.edu Univ of Washington, Seattle, WA 98125 Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications