forums.silverfrost.com

[simon]

There are a few features of Fortran 2003 and 2008 that are available in alternative form as Silverfrost extensions. How easy would it be to implement such features following the standards?

Examples include:

GETENV@ for the 2003 intrinsic subroutine GET_ENVIRONMENT_VARIABLE
COMMAND_LINE for the 2003 intrinsic GET_COMMAND
START_PROCESS@ for the 2008 intrinsic EXECUTE_COMMAND_LINE

[PaulLaidler]

Thanks Simon.

GET_COMMAND is already provided. The others two should be fairly easy to add.

[DanRRight]

One of third party codes I use written in gFortran started using Fortran 2003 FLUSH, the only what FTN95 does not have being in all other respects superior to gFortran, at least with this specific code (FTN95 found like a billion of small and pretty serious bugs making this code stable and results believable). Though there exist workaround for FLUSH it would be probably good to eventually have it in FTN95

[PaulLaidler]

OK I will add FLUSH to the list.

[PaulLaidler]

These features have now been added to FTN95 for the next release (after v8.40).

[DanRRight]

Thanks

[PaulLaidler]

Yes there is a topic on this but it is not up to date.

See FTN95->FTN95 Fortran language extensions->Extensions to FTN95 from the Fortran 2003 standard.

[JohnCampbell]

For me, the most important extension to Fortran 95 was not even part of F2003. This was TR15581 released in 1998 then 2001 which extended the functionality of ALLOCATE. The ability to return a modified allocatable array in a routine call provides useful functionality for managing allocatable arrays, especially extending their size. (the approach in FTN95 is more awkward)

As well as new coding structures, F2003 and F2008 introduced a number of new intrinsic functions, some of which are provided in FTN95. There are a number of useful functions that are yet to be included, such as SIZEOF, Compiler_Version, Compiler_Options as well as those previously mentioned in this thread. Many of these functions do not require the new features in F2003 or F2008.

Support for the exceptions of the IEEE Floating Point Standard (IEEE 1989) is also pre F2003, although I don't know the significance of this requirement.

Support for ISO_FORTRAN_ENV module would provide for improved portability and conformity with the newer Fortran approach.

The other main change in recent Fortran usage is support for OpenMP, which is not part of the Fortran Standard. FTN95 Ver 8 has introduced some multi-thread functionality, but some of the OpenMP structures would help, at least to OpenMP version 3. Support for the concept of shared and private variables/arrays is essential.

It would be good if some of these could be scheduled for inclusion in FTN95, although given the experience of 64-bit, that may be a big ask !

The big strengths of FTN95 remains it's Checkmate/SDBG functionality and support for Clearwin+.

John

[PaulLaidler]

John

Can you provide a short and simple list of your desired new features in order of importance to you.

[JohnCampbell]

Paul,

Thanks for the offer. I will review past posts and provide my ordered list.

[mecej4]

Paul, is the implementation of TR15581 (allocatable array arguments, https://wg5-fortran.org/N1351-N1400/N1379.pdf) still on the wish list, as I hope? Please see http://forums.silverfrost.com/viewtopic.php?t=2951 .

As you can see from that thread, John Campbell did express an interest in that feature, and I certainly see that feature as very convenient for solving discretised 2D and 3D physical problems. The first two paragraphs of N1379.pdf under "Introduction" present the rationale for the feature.

All currently marketed Fortran compilers (other than FTN95) for Windows and Linux support TR15581.

A simple example of using this feature is as as follows. In a subroutine, two integers are read from a data file, a 2-D array with those dimensions is allocated, and values are read into the array from the same data file. The newly allocated and populated array is returned to the caller for subsequent processing (factorization, QR decomposition, etc.).

[PaulLaidler]

mecej4

Yes this is high on the list.

[mecej4]

That's nice to hear. Thanks.

[JohnCampbell]

Commenting on the addition of TR15581 functionality:
When using FTN95 at present, the approach required for modifying allocatable arrays is to place the allocatable array in a MODULE and address it directly in the routine. As well as allocating, the other task is to check and re-size allocatable arrays if they are required to store more information.
This approach is limiting, as only a specific array can be defined.

TR15581, allows allocatable arrays to be routine arguments and so can be defined or adjusted when required, rather than designed in the routine hierarchy. This provides for routines to be more general and deal with multiple arrays of the same rank.

The other complexity of this additional functionality is the use of INTENT with ALLOCATABLE which can imply automatic deallocation.
TR15581 is not a trivial change, but would be very helpful.

The other changes I have been requesting are hopefully less complex. They are :
1) to include "information" intrinsic procedures that have been provided in F2003 and F2008. This assists in standardising the approach/name for information that is often available with other FTN95 library routines.
2) to provide other information routines that are becoming more useful (hopefully to others as well), such as GlobalMemoryStatusEx and others that have been identified lately.
3) to provide a version of ISO_FORTRAN_ENV module that covers the features in FTN95 that are included in the F2003 and F2008 module definition.

I would hope that the features selected in this list are easy to implement and so provides a coding path for improved portability and extent the usefulness of FTN95, which is my primary development compiler.

The other wish I would have is support for some OpenMP functionality, using the !$OMP directives. FTN95 has recently provided some multi-threaded capability, but the addition of PRIVATE variable construction would be very helpful. Unfortunately, this may be a much more complex addition. I would like to suggest support of OpenMP Version 3.0 or 3.1, but I am sure requests for later more complex versions would soon come.

Some indication on what is more likely or easier to achieve would be informative.

(apologies this post is similar to my previous post, but does provide some additional info. I have been on holidays on the beach, so have forgotten what I did last year, which is becoming an issue for us Fortran programmers !!)

[PaulLaidler]

John

Thank you for the feedback.

I understand about TR15581 but your items 1-3 are somewhat vague. If you can be more specific then that would help. OpenMP seems to be unrealistic to me at the moment.

I am not sure if you know this but GlobalMemoryStatus@ already provides access to GlobalMemoryStatusEx.