![forums.silverfrost.com Forum Index](templates/subSilver/images/logo_phpBB.gif) |
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
simon
Joined: 05 Jul 2006 Posts: 270
|
Posted: Thu Apr 06, 2017 8:36 pm Post subject: Fortran 2003 and 2008 features |
|
|
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 |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7995 Location: Salford, UK
|
Posted: Thu Apr 06, 2017 9:46 pm Post subject: |
|
|
Thanks Simon.
GET_COMMAND is already provided. The others two should be fairly easy to add. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
DanRRight
Joined: 10 Mar 2008 Posts: 2845 Location: South Pole, Antarctica
|
Posted: Fri Apr 07, 2017 7:14 am Post subject: |
|
|
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 |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7995 Location: Salford, UK
|
Posted: Fri Apr 07, 2017 7:33 am Post subject: |
|
|
OK I will add FLUSH to the list. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7995 Location: Salford, UK
|
Posted: Wed Dec 12, 2018 4:02 pm Post subject: |
|
|
These features have now been added to FTN95 for the next release (after v8.40). |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
DanRRight
Joined: 10 Mar 2008 Posts: 2845 Location: South Pole, Antarctica
|
Posted: Thu Dec 13, 2018 9:24 am Post subject: |
|
|
Thanks |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7995 Location: Salford, UK
|
Posted: Tue Dec 18, 2018 4:23 pm Post subject: |
|
|
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. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2575 Location: Sydney
|
Posted: Sat Jan 12, 2019 7:47 am Post subject: |
|
|
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 |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7995 Location: Salford, UK
|
Posted: Sat Jan 12, 2019 9:16 am Post subject: |
|
|
John
Can you provide a short and simple list of your desired new features in order of importance to you. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2575 Location: Sydney
|
Posted: Wed Jan 16, 2019 11:36 am Post subject: |
|
|
Paul,
Thanks for the offer. I will review past posts and provide my ordered list. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
mecej4
Joined: 31 Oct 2006 Posts: 1896
|
Posted: Mon Jan 21, 2019 1:38 pm Post subject: |
|
|
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.). |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7995 Location: Salford, UK
|
Posted: Mon Jan 21, 2019 6:04 pm Post subject: |
|
|
mecej4
Yes this is high on the list. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
mecej4
Joined: 31 Oct 2006 Posts: 1896
|
Posted: Mon Jan 21, 2019 6:56 pm Post subject: |
|
|
That's nice to hear. Thanks. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
JohnCampbell
Joined: 16 Feb 2006 Posts: 2575 Location: Sydney
|
Posted: Tue Jan 22, 2019 3:00 am Post subject: |
|
|
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 !!) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7995 Location: Salford, UK
|
Posted: Tue Jan 22, 2019 8:46 am Post subject: |
|
|
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. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|