• DATA statements enclosed in parentheses

    From John Collins@21:1/5 to All on Fri Apr 1 11:21:01 2022
    Working on some old, but commercially important code, we found DATA statements of the form, e.g.

    DATA (c = 2.99792458D8, pi = 3.1415926536D0)

    This compiles in the original VMS environment and (no surprise) under ifort and CVF. gfortran very reasonably doesn't like it.

    However, this seems a more regular syntax than the standard. Does anyone know the history?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to john.c...@simconglobal.com on Fri Apr 1 19:20:08 2022
    On Saturday, April 2, 2022 at 5:21:03 AM UTC+11, john.c...@simconglobal.com wrote:
    Working on some old, but commercially important code, we found DATA statements of the form, e.g.

    DATA (c = 2.99792458D8, pi = 3.1415926536D0)

    This compiles in the original VMS environment and (no surprise) under ifort and CVF. gfortran very reasonably doesn't like it.
    .
    Just change it to the standard.
    .
    However, this seems a more regular syntax than the standard. Does anyone know the history?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ev. Drikos@21:1/5 to John Collins on Sat Apr 2 05:50:37 2022
    On 01/04/2022 21:21, John Collins wrote:
    Working on some old, but commercially important code, we found DATA statements of the form, e.g.

    DATA (c = 2.99792458D8, pi = 3.1415926536D0)

    This compiles in the original VMS environment and (no surprise) under ifort and CVF. gfortran very reasonably doesn't like it.

    However, this seems a more regular syntax than the standard. Does anyone know the history?


    Admittedly, I don't know the history!

    IMHO however this DATA statement phenomenicaly has similarities with
    a compiler specific version of the PARAMETER statement, and so I tried
    the first example below.

    GNU Fortran however likely fails to parse some "io-implied-do" objects
    as we can see from the second example below. Not sure if I faced some
    typo in the html page I found the statement of the second example or
    it's another variant of a compiler specific DATA statement as well.


    -------------------------------------------------------------------
    $ cat data.f90 && gfc -DDATA=PARAMETER data.F90 && ./a.out
    DATA (c = 2.99792458D8 , pi = 3.1415926536D0 )
    PRINT *, c, pi
    END
    299792448. 3.14159274

    -------------------------------------------------------------------
    $ cat data2.f90 && gfortran -ffixed-form data2.f90
    DATA ( S(I,I), I=1,4)/4.0/

    !https://docs.oracle.com/cd/E19957-01/805-4939/6j4m0vn85/index.html
    ! See that these two lines differ!
    ! DATA ( S(I,I), I=1,4)/4*1.0/, ( R(I,J), J=1,3), I=1,2)/6*1.0/
    DATA ( S(I,I), I=1,4)/4*1.0/, ((R(I,J), J=1,3), I=1,2)/6*1.0/
    END
    data2.f90:1.15:

    DATA ( S(I,I), I=1,4)/4.0/
    1
    Error: Syntax error in DATA statement at (1)
    data2.f90:6.15:

    DATA ( S(I,I), I=1,4)/4*1.0/, ((R(I,J), J=1,3), I=1,2)/6*1.0/
    1
    Error: Syntax error in DATA statement at (1)
    $

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ev. Drikos@21:1/5 to Ev. Drikos on Sat Apr 2 07:15:47 2022
    On 02/04/2022 05:50, Ev. Drikos wrote:
    ...

    GNU Fortran however likely fails to parse some "io-implied-do" objects
    as we can see from the second example below. Not sure if I faced some
    typo in the html page I found the statement of the second example or
    it's another variant of a compiler specific DATA statement as well.



    Oh, I forgot the array declarations. So, gfortran is ok!!!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to john.c...@simconglobal.com on Fri Apr 1 23:09:13 2022
    On Friday, April 1, 2022 at 11:21:03 AM UTC-7, john.c...@simconglobal.com wrote:
    Working on some old, but commercially important code, we found DATA statements of the form, e.g.

    DATA (c = 2.99792458D8, pi = 3.1415926536D0)

    This compiles in the original VMS environment and (no surprise) under ifort and CVF. gfortran very reasonably doesn't like it.

    It is not in VAX Fortran of 1984. Which VMS versions have it?

    However, this seems a more regular syntax than the standard. Does anyone know the history?

    The regular syntax is in Fortran 66. Maybe earlier than that.

    I do remember some strange things from CDC Fortran, especially with their use of a 6 bit character set. Even so, I don't know that they would do that.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Collins@21:1/5 to All on Sat Apr 2 09:11:39 2022
    @gah4
    It is not in VAX Fortran of 1984. Which VMS versions have it?

    We found this on Itanium, listing gives: COMPILER: VSI Fortran V8.3-104956-50P85
    This is interesting because if it wasn't on VMS Fortran in 1984 then someone added it later. We found it in code which was running on Itanium VMS but dated from the 1980s or before.

    I like the syntax - standard DATA statement syntax forces a special case handler for a general expression and this doesn't. It is not a major issue - no-one will change the DATA statement syntax now, but I am curious.

    It is supported by DVF/CVF and ifort. Perhaps Steve Lionel can comment?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to john.c...@simconglobal.com on Sat Apr 2 15:59:03 2022
    On Saturday, April 2, 2022 at 9:11:41 AM UTC-7, john.c...@simconglobal.com wrote:
    @gah4
    It is not in VAX Fortran of 1984. Which VMS versions have it?

    We found this on Itanium, listing gives: COMPILER: VSI Fortran V8.3-104956-50P85
    This is interesting because if it wasn't on VMS Fortran in 1984 then someone added it later. We found it in code which was running on Itanium VMS but dated from the 1980s or before.

    The one that I know, is that VAX Fortran didn't get past Fortran 77,
    but Alpha and Itanium did. I don't know if that helps, though.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to All on Sun Apr 3 11:14:38 2022
    On 4/2/22 5:59 PM, gah4 wrote:
    On Saturday, April 2, 2022 at 9:11:41 AM UTC-7, john.c...@simconglobal.com wrote:
    @gah4
    It is not in VAX Fortran of 1984. Which VMS versions have it?

    We found this on Itanium, listing gives: COMPILER: VSI Fortran V8.3-104956-50P85
    This is interesting because if it wasn't on VMS Fortran in 1984 then someone added it later. We found it in code which was running on Itanium VMS but dated from the 1980s or before.

    The one that I know, is that VAX Fortran didn't get past Fortran 77,
    but Alpha and Itanium did. I don't know if that helps, though.

    I have always been perplexed about that era of computing. The VAX
    hardware supported 4-byte, two different 8-byte, and 16-byte floating
    point arithmetic. The 4- and 8-byte formats had hardware support
    (depending on the VAX model I think), the 16-byte was mixed hardware and software. That was an ideal situation for the way f90 could declare and
    support all those different kinds. Yet, for some reason, the VAX never supported an f90 compiler.

    The Alpha and Itanium compilers supported those different floating point formats to various extents, but I think they just did it by converting
    the values to ieee format, they did not try to emulate the actual VAX arithmetic.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Phillip Helbig (undress to reply@21:1/5 to nospam@nowhere.org on Sun Apr 3 17:06:46 2022
    In article <QJj2K.526147$LN2.439229@fx13.iad>, Ron Shepard
    <nospam@nowhere.org> writes:

    It is not in VAX Fortran of 1984. Which VMS versions have it?

    We found this on Itanium, listing gives: COMPILER: VSI Fortran V8.3-104956-50P85
    This is interesting because if it wasn't on VMS Fortran in 1984 then someone added it later. We found it in code which was running on Itanium VMS but dated from the 1980s or before.

    The one that I know, is that VAX Fortran didn't get past Fortran 77,
    but Alpha and Itanium did. I don't know if that helps, though.

    I have always been perplexed about that era of computing. The VAX
    hardware supported 4-byte, two different 8-byte, and 16-byte floating
    point arithmetic. The 4- and 8-byte formats had hardware support
    (depending on the VAX model I think), the 16-byte was mixed hardware and software. That was an ideal situation for the way f90 could declare and support all those different kinds. Yet, for some reason, the VAX never supported an f90 compiler.

    By the time the standard came out, VAX was on the way out. I think
    that it was a good decision to say that Fortran 90 would be Alpha-only, especially since most Fortran users probably wanted a fast machine, and
    early Alphas were both faster and cheaper than comparable VAX models.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Lionel@21:1/5 to John Collins on Wed Apr 13 12:52:01 2022
    On 4/2/2022 12:11 PM, John Collins wrote:
    @gah4
    It is not in VAX Fortran of 1984. Which VMS versions have it?

    We found this on Itanium, listing gives: COMPILER: VSI Fortran V8.3-104956-50P85
    This is interesting because if it wasn't on VMS Fortran in 1984 then someone added it later. We found it in code which was running on Itanium VMS but dated from the 1980s or before.

    I like the syntax - standard DATA statement syntax forces a special case handler for a general expression and this doesn't. It is not a major issue - no-one will change the DATA statement syntax now, but I am curious.

    It is supported by DVF/CVF and ifort. Perhaps Steve Lionel can comment?


    I do not recall ever seeing that DATA syntax before. I am fairly certain
    that the VAX FORTRAN-77 compiler did not support it. The DEC F90
    compiler, though, was based on a front-end (language parser) from
    COMPASS, and a number of COMPASS compiler developers were hired into the
    DEC Fortran team. Over the years we discovered all sorts of weird syntax extensions that COMPASS had inserted. Some of these got removed when
    they were found. Needless to say, this one is not documented.

    I do note that ifort/ifx doesn't complain about it if you ask for
    standards checking, which is a bug that I reported as issue 05437508.

    It does not astonish me that VSI Fortran supports it as HP forked the
    DEC Fortran 90 compiler in the early years after the acquisition of
    Compaq by HP. I think Intel provided some bug fixes for a few years, but
    not new features. The VSI folk have had to reimplement the post-F95
    features (the compiler was mostly F95 by that time and even had some of
    the TR15581 features, such as allocatable components in derived type.)

    My advice echoes others - replace the statement with standard syntax.

    --
    Steve Lionel
    ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
    Retired Intel Fortran developer/support
    Email: firstname at firstnamelastname dot com
    Twitter: @DoctorFortran
    LinkedIn: https://www.linkedin.com/in/stevelionel
    Blog: https://stevelionel.com/drfortran
    WG5: https://wg5-fortran.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Lionel@21:1/5 to Ron Shepard on Wed Apr 13 12:23:40 2022
    On 4/3/2022 12:14 PM, Ron Shepard wrote:
    The Alpha and Itanium compilers supported those different floating point formats to various extents, but I think they just did it by converting
    the values to ieee format, they did not try to emulate the actual VAX arithmetic.

    I'm not sure about Itanium (tried to forget that), but Alpha had native
    support for VAX single and double floating point formats and their
    semantics. I have a faint recollection of there being something about
    VAX D being treated internally as 53-bit mantissa instead of 56 bit, but
    I could be misremembering.

    On Alpha VMS, you could specify at compile time whether you wanted VAX
    F/D, VAX F/G or IEEE S/T. Alpha supported IEEE quad format as "X float"
    and software was used to convert VAX "H float" to X. Fortran I/O
    supported conversion on read and write of all of these formats to and
    from what the source was compiled with, as well as IBM/360 and CRAY
    formats. (I wrote the run-time support for this.)

    --
    Steve Lionel
    ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
    Retired Intel Fortran developer/support
    Email: firstname at firstnamelastname dot com
    Twitter: @DoctorFortran
    LinkedIn: https://www.linkedin.com/in/stevelionel
    Blog: https://stevelionel.com/drfortran
    WG5: https://wg5-fortran.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Collins@21:1/5 to Steve Lionel on Wed Apr 13 11:04:14 2022
    On Wednesday, April 13, 2022 at 5:52:07 PM UTC+1, Steve Lionel wrote:
    <snip>>
    My advice echoes others - replace the statement with standard syntax.
    --
    Thank you. We have changed the syntax to standard.
    We have automated the replacement because we found several of them and there might be more. Also we had previously automated moving DATA for variables in COMMON to BLOCK DATA and we didn't want to rewrite that code for this new, exciting syntax.

    But:

    The standard syntax for the DATA statement is archaic. It requires an unique meaning for the * operator and an odd use of /. Shows its age!
    This syntax is far more in keeping with the principal of least astonishment. Is there any chance of adding it to the standard?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Lionel@21:1/5 to John Collins on Wed Apr 13 15:18:26 2022
    On 4/13/2022 2:04 PM, John Collins wrote:
    The standard syntax for the DATA statement is archaic. It requires an unique meaning for the * operator and an odd use of /. Shows its age!
    This syntax is far more in keeping with the principal of least astonishment. Is there any chance of adding it to the standard?

    This is why the "modern Fortran" way is to do initialization on the
    statement that declares the variable. DATA itself is archaic (though not
    yet obsolescent), dating from the era of implicit type declarations.
    Given that there is a newer way to do initialization; one that doesn't
    require the compiler to stand on its head to make sense of overlapping
    DATA statements, I see no motive for simply altering the syntax of DATA.

    As for the use of * and /, these do show up in other places. * as a
    repeat count appears in list-directed and NAMELIST I/O, and slash as a delimiter is used for COMMON.

    --
    Steve Lionel
    ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
    Retired Intel Fortran developer/support
    Email: firstname at firstnamelastname dot com
    Twitter: @DoctorFortran
    LinkedIn: https://www.linkedin.com/in/stevelionel
    Blog: https://stevelionel.com/drfortran
    WG5: https://wg5-fortran.org

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Steve Lionel on Wed Apr 13 16:05:55 2022
    On Wednesday, April 13, 2022 at 9:23:44 AM UTC-7, Steve Lionel wrote:
    On 4/3/2022 12:14 PM, Ron Shepard wrote:
    The Alpha and Itanium compilers supported those different floating point formats to various extents, but I think they just did it by converting
    the values to ieee format, they did not try to emulate the actual VAX arithmetic.

    I'm not sure about Itanium (tried to forget that), but Alpha had native support for VAX single and double floating point formats and their
    semantics. I have a faint recollection of there being something about
    VAX D being treated internally as 53-bit mantissa instead of 56 bit, but
    I could be misremembering.

    On Alpha VMS, you could specify at compile time whether you wanted VAX
    F/D, VAX F/G or IEEE S/T. Alpha supported IEEE quad format as "X float"
    and software was used to convert VAX "H float" to X.

    I once knew about this.

    As well as I remember, the F/D/G/H load/store instructions convert
    between VAX byte order and Alpha byte order, even if they don't do
    anything else. I don't remember now the exact difference, once
    you change the byte order, between VAX and IEEE. There might
    be a different exponent bias. And yes, it seems familiar, that for
    D Float it throws away the three bits.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Steve Lionel on Wed Apr 13 17:32:50 2022
    On Wednesday, April 13, 2022 at 12:18:31 PM UTC-7, Steve Lionel wrote:

    (snip)

    This is why the "modern Fortran" way is to do initialization on the
    statement that declares the variable. DATA itself is archaic (though not
    yet obsolescent), dating from the era of implicit type declarations.
    Given that there is a newer way to do initialization; one that doesn't require the compiler to stand on its head to make sense of overlapping
    DATA statements, I see no motive for simply altering the syntax of DATA.

    The IBM and some DEC Fortran compilers, at least to Fortran 66 days,
    have a different declaration/initialization form:

    REAL X/1.2/, Y/2.4/, Z(3)/1.,2.,3./

    unlike DATA where you can initialize more that one variable with a group:

    DATA X, Y, Z/1.2, 2.4,1.,2,.3./

    you can only initialize the preceding variable (or array).

    I don't remember that this ever got into any standard, though.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From John Collins@21:1/5 to All on Thu Apr 14 03:28:31 2022
    On Thursday, April 14, 2022 at 1:32:52 AM UTC+1, gah4 wrote:
    On Wednesday, April 13, 2022 at 12:18:31 PM UTC-7, Steve Lionel wrote:

    (snip)
    This is why the "modern Fortran" way is to do initialization on the statement that declares the variable. DATA itself is archaic (though not yet obsolescent), dating from the era of implicit type declarations.
    Given that there is a newer way to do initialization; one that doesn't require the compiler to stand on its head to make sense of overlapping DATA statements, I see no motive for simply altering the syntax of DATA.

    I have made a compiler 'stand on its head' to handle DATA statements, and I agree strongly that the existing syntax has problems. But I don't think that the DATA statement can be replaced by embedded data in declarations in all cases. The following is
    a fragment from the data construct in fpt which specifies the name labels for intrinsic function and subroutine arguments:

    DATA itr_lab_arg(:,k_len)/k_string,0,0,0,0,0/
    DATA itr_lab_arg(:,k_index)/k_string,k_substring,k_back,0,0,0/
    DATA itr_lab_arg(:,k_char)/k_i,k_kind,0,0,0,0/
    DATA itr_lab_arg(:,k_ichar)/k_c,k_kind,0,0,0,0/
    DATA itr_lab_arg(:,k_llt)/k_string_a,k_string_b,0,0,0,0/
    DATA itr_lab_arg(:,k_lle)/k_string_a,k_string_b,0,0,0,0/
    DATA itr_lab_arg(:,k_lgt)/k_string_a,k_string_b,0,0,0,0/
    DATA itr_lab_arg(:,k_lge)/k_string_a,k_string_b,0,0,0,0/
    DATA itr_lab_arg(:,k_sizeof)/0,0,0,0,0,0/

    0 means no pre-defined label name. There is a unique integer value corresponding to every name, with the parameter value k_name. k_name specifies that the name corresponds to the serial position of the argument. There is an entry for every standard
    intrinsic and every intrinsic in VMS, MPX and HP3000 ... Fortran. There are similar tables for the data type and kind of the intrinsic returns. These have to be maintained by hand - the standard changes. I do not see how this information could be
    embedded in the declaration of itr_lab_arg. But if it can, I would be very happy!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)