• Fortran still going strong on TIOBE index

    From Lynn McGuire@21:1/5 to Rudi Gaelzer on Wed Jul 7 15:02:29 2021
    On 7/7/2021 10:28 AM, Rudi Gaelzer wrote:
    On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
    Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
    and still going up; possibly to the 13th. or 12th. position in the next report.
    I think this is auspicious news.
    What do you think were the causes of this renewed raise on the interest of Fortran?

    Lots of very old programs out there are written in F66 or F77 and their mainframes are going away. Time to port to Windows, Linux, or Unix !

    I wonder how many of the programmers even know Fortran and understand
    nuances such as automatic zero initialization ?

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jos Bergervoet@21:1/5 to Rudi Gaelzer on Wed Jul 7 23:33:13 2021
    On 21/07/07 5:28 PM, Rudi Gaelzer wrote:
    On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
    Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
    and still going up; possibly to the 13th. or 12th. position in the next report.
    I think this is auspicious news.
    What do you think were the causes of this renewed raise on the interest of Fortran?

    People start to realize there aren't many languages that have:

    1) A language evolution based on steady, backward-compatible changes.
    2) An unambiguous language definition, maintained by a standardization
    committee.
    3) A high enough age to be reasonably complete despite the very
    slow progress guaranteed by points 1) and 2).
    4) A large code base and libraries for most things you need.
    5) A compiler included in the public domain gcc compiler suite.
    6) An excellent reputation for execution speed.
    7) Parallel programming as integrated part of the language.

    It is understandable that this took some time to sink in, since some of
    these things are a bit paradoxical. Especially the fact that Fortran
    is as advanced as it is precisely because it is as old as it is.

    But I think the list shows that the TIOBE ranking is well-deserved.

    --
    Jos

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From FortranFan@21:1/5 to Jos Bergervoet on Wed Jul 7 17:22:01 2021
    On Wednesday, July 7, 2021 at 5:36:03 PM UTC-4, Jos Bergervoet wrote:

    ..
    People start to realize there aren't many languages that have:

    1) A language evolution based on steady, backward-compatible changes.
    2) An unambiguous language definition, maintained by a standardization committee.
    3) A high enough age to be reasonably complete despite the very
    slow progress guaranteed by points 1) and 2).
    4) A large code base and libraries for most things you need.
    5) A compiler included in the public domain gcc compiler suite.
    6) An excellent reputation for execution speed.
    7) Parallel programming as integrated part of the language.

    It is understandable that this took some time to sink in, since some of
    these things are a bit paradoxical. Especially the fact that Fortran
    is as advanced as it is precisely because it is as old as it is.

    But I think the list shows that the TIOBE ranking is well-deserved.
    ..

    Nice way to rationalize *whatever* might be going on that simply cannot be understood exactly but which makes Fortran move up the ranking!

    This graph at the same ranking site might also be revealing, suggesting whatever is going on might be fleeting:
    https://www.tiobe.com/tiobe-index/fortran/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From JCampbell@21:1/5 to Lynn McGuire on Wed Jul 7 20:12:03 2021
    On Thursday, July 8, 2021 at 6:02:34 AM UTC+10, Lynn McGuire wrote:

    I wonder how many of the programmers even know Fortran and understand
    nuances such as automatic zero initialization ?

    Lynn
    I wonder how many Fortran programmers know where in the standard "automatic zero initialization" is discussed ?

    It is my impression this is not assumed in the standard, but I must be a Fortran user who doesn't know.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Lynn McGuire on Wed Jul 7 21:14:07 2021
    On Thursday, July 8, 2021 at 6:02:34 AM UTC+10, Lynn McGuire wrote:
    On 7/7/2021 10:28 AM, Rudi Gaelzer wrote:
    On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
    Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
    and still going up; possibly to the 13th. or 12th. position in the next report.
    I think this is auspicious news.
    What do you think were the causes of this renewed raise on the interest of Fortran?
    .
    Lots of very old programs out there are written in F66 or F77
    .
    and FORTRAN IV
    .
    and their
    mainframes are going away. Time to port to Windows, Linux, or Unix !

    I wonder how many of the programmers even know Fortran and understand
    nuances such as automatic zero initialization ?
    .
    There is no automatic zero initialization.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Jos Bergervoet on Wed Jul 7 21:25:18 2021
    On Thursday, July 8, 2021 at 7:36:03 AM UTC+10, Jos Bergervoet wrote:
    On 21/07/07 5:28 PM, Rudi Gaelzer wrote:
    On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
    Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
    and still going up; possibly to the 13th. or 12th. position in the next report.
    I think this is auspicious news.
    What do you think were the causes of this renewed raise on the interest of Fortran?
    People start to realize there aren't many languages that have:

    1) A language evolution based on steady, backward-compatible changes.
    .
    A number of old features are no longer standard and have been deleted
    or are due to be deleted.
    A number of old "features" that continue to be used, were never standard.
    .
    2) An unambiguous language definition, maintained by a standardization committee.
    .
    Ambiguous definitions arise in the case of certain COMPLEX constructs
    that are error-prone.
    .
    The KIND specification is ambiguous, and can catch anyone.
    .
    3) A high enough age to be reasonably complete despite the very
    slow progress guaranteed by points 1) and 2).
    4) A large code base and libraries for most things you need.
    5) A compiler included in the public domain gcc compiler suite.
    6) An excellent reputation for execution speed.
    7) Parallel programming as integrated part of the language.

    It is understandable that this took some time to sink in, since some of
    these things are a bit paradoxical. Especially the fact that Fortran
    is as advanced as it is precisely because it is as old as it is.

    But I think the list shows that the TIOBE ranking is well-deserved.
    .
    People start to realize there aren't many languages that have:
    .
    One such language is PL/I, which was introduced as an an improved
    FORTRAN -- and a vast improvement it was! (and still is).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to Jos Bergervoet on Thu Jul 8 14:20:11 2021
    Jos Bergervoet <jos.bergervoet@xs4all.nl> schrieb:
    On 21/07/07 5:28 PM, Rudi Gaelzer wrote:
    On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
    Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
    and still going up; possibly to the 13th. or 12th. position in the next report.
    I think this is auspicious news.
    What do you think were the causes of this renewed raise on the interest of Fortran?

    People start to realize there aren't many languages that have:

    1) A language evolution based on steady, backward-compatible changes.

    And that is a _huge_ advantage.

    Compare this to the C++ approach, where a serious discussion paper
    co-authored by two WG21 members advocates dropping backwards and
    forwards compatibility:

    http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2137r0.html

    This paper should be enough to give anybody the creeps.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dpb@21:1/5 to Rudi Gaelzer on Thu Jul 8 09:19:56 2021
    On 7/7/2021 10:28 AM, Rudi Gaelzer wrote:
    On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
    Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
    and still going up; possibly to the 13th. or 12th. position in the next report.
    I think this is auspicious news.
    What do you think were the causes of this renewed raise on the interest of Fortran?

    Given the manner in which those rankings are computed, I don't believe
    there's any way to prove any correlation to any real application of Fortran.

    At the level of those numbers; wild fluctuations are possible and mostly
    what it "measures" is just random noise.

    --

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jos Bergervoet@21:1/5 to Robin Vowels on Thu Jul 8 19:36:39 2021
    On 21/07/08 6:25 AM, Robin Vowels wrote:
    On Thursday, July 8, 2021 at 7:36:03 AM UTC+10, Jos Bergervoet wrote:
    On 21/07/07 5:28 PM, Rudi Gaelzer wrote:
    On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
    Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
    and still going up; possibly to the 13th. or 12th. position in the next report.
    I think this is auspicious news.
    What do you think were the causes of this renewed raise on the interest of Fortran?
    People start to realize there aren't many languages that have:

    1) A language evolution based on steady, backward-compatible changes.
    .
    A number of old features are no longer standard and have been deleted
    or are due to be deleted.
    A number of old "features" that continue to be used, were never standard.

    In the first decades of its life, FORTRAN fooled around just like
    those young languages we see around us now! But with age comes
    responsibility, and that's probably what we're seeing here.

    .
    2) An unambiguous language definition, maintained by a standardization
    committee.
    .
    Ambiguous definitions arise in the case of certain COMPLEX constructs
    that are error-prone.
    .
    The KIND specification is ambiguous, and can catch anyone.

    If any ambiguities still pop up then at least an 'interpretation' of
    the rules can be given by the standardization body to resolve the
    issue.

    .
    3) A high enough age to be reasonably complete despite the very
    slow progress guaranteed by points 1) and 2).
    4) A large code base and libraries for most things you need.
    5) A compiler included in the public domain gcc compiler suite.
    6) An excellent reputation for execution speed.
    7) Parallel programming as integrated part of the language.

    It is understandable that this took some time to sink in, since some of
    these things are a bit paradoxical. Especially the fact that Fortran
    is as advanced as it is precisely because it is as old as it is.

    But I think the list shows that the TIOBE ranking is well-deserved.
    .
    People start to realize there aren't many languages that have:
    .
    One such language is PL/I, which was introduced as an an improved
    FORTRAN -- and a vast improvement it was! (and still is).

    But PL/I doesn't have points 4), 5) and 7), to name a few.

    --
    Jos

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to JCampbell on Thu Jul 8 15:52:40 2021
    On 7/7/2021 10:12 PM, JCampbell wrote:
    On Thursday, July 8, 2021 at 6:02:34 AM UTC+10, Lynn McGuire wrote:

    I wonder how many of the programmers even know Fortran and understand
    nuances such as automatic zero initialization ?

    Lynn
    I wonder how many Fortran programmers know where in the standard "automatic zero initialization" is discussed ?

    It is my impression this is not assumed in the standard, but I must be a Fortran user who doesn't know.

    No, automatic zero initialization for local variables was never a part
    of the standard. It came into place as the mainframes had multiple
    users and would zero initialize memory pages before usage by a program
    to keep programs from accessing what was there by a previous user.
    Modern cpus put random values, not zeros, into memory pages before usage
    now.

    Unfortunately, programmers started to assume that local variables did
    not require initialization and wrote software accordingly. So Fortran
    software dating to the 1960s, 1970s, and 1980s will probably have
    problems with local variable initialization. YMMV (your mileage may
    vary !).

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Robin Vowels on Thu Jul 8 15:44:53 2021
    On 7/7/2021 11:14 PM, Robin Vowels wrote:
    On Thursday, July 8, 2021 at 6:02:34 AM UTC+10, Lynn McGuire wrote:
    On 7/7/2021 10:28 AM, Rudi Gaelzer wrote:
    On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
    Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
    and still going up; possibly to the 13th. or 12th. position in the next report.
    I think this is auspicious news.
    What do you think were the causes of this renewed raise on the interest of Fortran?
    .
    Lots of very old programs out there are written in F66 or F77
    .
    and FORTRAN IV
    .
    and their
    mainframes are going away. Time to port to Windows, Linux, or Unix !

    I wonder how many of the programmers even know Fortran and understand
    nuances such as automatic zero initialization ?
    .
    There is no automatic zero initialization.

    Fortran IV is Fortran 66.

    All Fortran code developed on Univac 1108s or IBM mainframes or using
    the Unix F77 compiler had automatic zero initialization as a feature.
    Most Fortran programmers never realized that local variables should be initialized until it was too late.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to dpb on Thu Jul 8 18:45:29 2021
    On 7/8/2021 9:19 AM, dpb wrote:
    On 7/7/2021 10:28 AM, Rudi Gaelzer wrote:
    On April last, it was reported that Fortran had returned to the top 20
    languages, according to the TIOBE index.
    Now, the July report shows that Fortran climbed to the 14th. position:
    https://www.tiobe.com/tiobe-index/
    and still going up; possibly to the 13th. or 12th. position in the
    next report.
    I think this is auspicious news.
    What do you think were the causes of this renewed raise on the
    interest of Fortran?

    Given the manner in which those rankings are computed, I don't believe there's any way to prove any correlation to any real application of
    Fortran.

    At the level of those numbers; wild fluctuations are possible and mostly
    what it "measures" is just random noise.

    Probably as good as anything else for indicating interest / usage. I
    suspect a lot of old Fortran 66 /77 software is getting ported to
    Windows, Linux, and Unix servers now.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Lynn McGuire on Thu Jul 8 18:21:51 2021
    On Thursday, July 8, 2021 at 1:45:01 PM UTC-7, Lynn McGuire wrote:

    (snip)

    All Fortran code developed on Univac 1108s or IBM mainframes or using
    the Unix F77 compiler had automatic zero initialization as a feature.
    Most Fortran programmers never realized that local variables should be initialized until it was too late.

    IBM mainframes didn't (and don't) automatically zero initialization, but
    it can be done. One I knew (OS/360 days) initialized to X'81'.

    It is complicated, though. Such data isn't initialized at all by the compiler, but left has 'holes' in the object program. Each record (card) of the object program has a start address and length. None cover uninitialized data.

    The linkage editor then takes object programs and combines them.
    It likes to write out larger records, and so has to fill-in smaller such blocks. Older ones left whatever was in its own memory space.
    Later ones would initialize that space.

    But larger ones are not written to the load module, but, as with the
    object program are left out. In this case, it is whatever is in memory
    before load module fetch. Part of that is the initiator that opens
    data sets, and otherwise gets things ready, and then reads in the
    actual load module records. So this also has to be changed to actually initialize Fortran variables. As noted, it can be done.

    That is all before MVS. OS/360 uses only real storage addresses.
    OS/VS1 and OS/VS2 use a single virtual address space with all
    programs in it. By the time of MVS, it is likely that security
    requirements disallowed one program's data from being seen by
    others, but not from itself.
    But note as above, there are two places that have to be changed.
    Even if the OS zeros all pages, it still reads in the load module which
    might have already initialized such blocks with whatever is left
    over in the linkage editor memory.

    Fortran E, G, H, and VS Fortran all used only static allocation.
    As well as I know, there is no IBM supplied Fortran 90 or
    later compiler for descendants of OS/360.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Lynn McGuire on Thu Jul 8 18:31:36 2021
    On Thursday, July 8, 2021 at 1:52:48 PM UTC-7, Lynn McGuire wrote:

    (snip)

    No, automatic zero initialization for local variables was never a part
    of the standard. It came into place as the mainframes had multiple
    users and would zero initialize memory pages before usage by a program
    to keep programs from accessing what was there by a previous user.
    Modern cpus put random values, not zeros, into memory pages before usage
    now.

    C requires static data, unless otherwise initialized, to be zero.
    Dynamic data (auto variables or malloc() allocated) is not necessarily zero.

    Last I knew, Linux uses a single zero initialized block, and maps that read only
    into any allocated space. Then, when the program writes to it, a new block is allocated, zeroed, and mapped into virtual address space.

    Unfortunately, programmers started to assume that local variables did
    not require initialization and wrote software accordingly. So Fortran software dating to the 1960s, 1970s, and 1980s will probably have
    problems with local variable initialization. YMMV (your mileage may
    vary !).

    Fortran compilers based on C compilers naturally tend to follow the zero
    of static space rule. As well as I know, they won't zero dynamically allocated memory. Since Fortran now allows for either static or automatic variables, other than those with the SAVE attribute, one can't be sure.

    The usual Unix-like systems don't need to write large blocks of zeroes into
    the object file or executable file. Non-zero data, they do. Initialize a (very)
    large Fortran array with all elements to the same non-zero value, they will
    all be written into the object program and executable file.

    integer :: X(100000000) = 1
    print *, x(1000000)
    end


    will give you a very large file.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Jos Bergervoet on Thu Jul 8 18:59:48 2021
    On Friday, July 9, 2021 at 3:38:04 AM UTC+10, Jos Bergervoet wrote:
    On 21/07/08 6:25 AM, Robin Vowels wrote:
    On Thursday, July 8, 2021 at 7:36:03 AM UTC+10, Jos Bergervoet wrote:
    On 21/07/07 5:28 PM, Rudi Gaelzer wrote:
    On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
    Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
    and still going up; possibly to the 13th. or 12th. position in the next report.
    I think this is auspicious news.
    What do you think were the causes of this renewed raise on the interest of Fortran?
    People start to realize there aren't many languages that have:

    1) A language evolution based on steady, backward-compatible changes.
    .
    A number of old features are no longer standard and have been deleted
    or are due to be deleted.
    A number of old "features" that continue to be used, were never standard.
    .
    In the first decades of its life, FORTRAN fooled around just like
    those young languages we see around us now! But with age comes responsibility, and that's probably what we're seeing here.
    .
    2) An unambiguous language definition, maintained by a standardization
    committee.
    .
    Ambiguous definitions arise in the case of certain COMPLEX constructs
    that are error-prone.
    .
    The KIND specification is ambiguous, and can catch anyone.
    .
    If any ambiguities still pop up then at least an 'interpretation' of
    the rules can be given by the standardization body to resolve the
    issue.
    .
    The ambiguities cited (COMPLEX, kind values) cannot be "resolved"
    by an "interpretation". Those are deficiencies in the design.
    30 years have now elapsed since these design flaws were introduced
    and still these flaws have not been fixed.
    .
    3) A high enough age to be reasonably complete despite the very
    slow progress guaranteed by points 1) and 2).
    4) A large code base and libraries for most things you need.
    5) A compiler included in the public domain gcc compiler suite.
    6) An excellent reputation for execution speed.
    7) Parallel programming as integrated part of the language.

    It is understandable that this took some time to sink in, since some of
    these things are a bit paradoxical. Especially the fact that Fortran
    is as advanced as it is precisely because it is as old as it is.

    But I think the list shows that the TIOBE ranking is well-deserved.
    .
    People start to realize there aren't many languages that have:
    .
    One such language is PL/I, which was introduced as an an improved
    FORTRAN -- and a vast improvement it was! (and still is).
    .
    But PL/I doesn't have points 4), 5) and 7), to name a few.
    .
    What? You think that PL/I does not lave a large code base and libraries
    for most things that you need?
    What? You think that PL/I does not have a public domain compiler?
    What? You think that PLI has no parallel programming? PL/I has
    had this since PL/I-F in 1966.
    What else do you think that PL/I does not have?
    Well, it does not have ambiguous definitions.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Lynn McGuire on Thu Jul 8 19:06:19 2021
    On Friday, July 9, 2021 at 6:45:01 AM UTC+10, Lynn McGuire wrote:
    On 7/7/2021 11:14 PM, Robin Vowels wrote:
    On Thursday, July 8, 2021 at 6:02:34 AM UTC+10, Lynn McGuire wrote:
    On 7/7/2021 10:28 AM, Rudi Gaelzer wrote:
    On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
    Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
    and still going up; possibly to the 13th. or 12th. position in the next report.
    I think this is auspicious news.
    What do you think were the causes of this renewed raise on the interest of Fortran?
    .
    Lots of very old programs out there are written in F66 or F77
    .
    and FORTRAN IV
    .
    and their
    mainframes are going away. Time to port to Windows, Linux, or Unix !

    I wonder how many of the programmers even know Fortran and understand
    nuances such as automatic zero initialization ?
    .
    There is no automatic zero initialization.
    Fortran IV is Fortran 66.
    .
    FORTRAN IV precedes FORTEAN 66.
    .
    All Fortran code developed on Univac 1108s or IBM mainframes
    .
    Not on IBM 360 it didn't.
    .
    or using
    the Unix F77 compiler had automatic zero initialization as a feature.
    Most Fortran programmers never realized that local variables should be initialized until it was too late.
    .
    That may be true (never realized...), but that last sentence contradicts what you wrote in the sentence before that.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to Lynn McGuire on Fri Jul 9 01:26:07 2021
    On 7/8/21 3:52 PM, Lynn McGuire wrote:
    Unfortunately, programmers started to assume that local variables did
    not require initialization and wrote software accordingly.

    I don't think this is a fair characterization of the fortran programmers
    I knew in the 1970s. Most of us knew that variables needed to be
    initialized, especially those of us who used overlay linkers. However,
    there were few tools, either static or runtime analyzers, that could
    locate such problems, so we wrote code that violated the standard by
    mistake, despite our efforts, not by intent.

    BTW, the univac 1108 I used in the 1970s did have an overlay linker, so
    the programmer had to know about initialization of variables, either
    with runtime assignments or with data and block data at compile time, to
    make that work.

    By the 1980s, tools did become available to check for uninitialized
    variables. These included compiler options and also separate analysis
    tools like ftnchek.

    The previous comment about IBM virtual memory reminded me of something
    odd. IBM thought that virtual memory was about dividing up the physical
    memory into smaller address spaces (e.g. for CMS time sharing among
    multiple users), while most other vendors used the term to describe
    using external disk space in order to run programs that were larger than
    the physical memory. From that perspective, those two were almost the
    opposite meaning.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Ron Shepard on Fri Jul 9 01:03:59 2021
    On Thursday, July 8, 2021 at 11:26:11 PM UTC-7, Ron Shepard wrote:

    (snip)
    The previous comment about IBM virtual memory reminded me of something
    odd. IBM thought that virtual memory was about dividing up the physical memory into smaller address spaces (e.g. for CMS time sharing among
    multiple users), while most other vendors used the term to describe
    using external disk space in order to run programs that were larger than
    the physical memory. From that perspective, those two were almost the opposite meaning.

    I am not so sure what IBM thought about it. The early OS/VS1 and OS/VS2
    systems worked like OS/360 MFT and MVT, respectively. The big problem
    with MVT was that after not so long, memory would be fragmented. To solve
    that, people (that I knew) always requested 300K. (That was the maximum
    for most job classes.) So, one advantage of OS/VS2 is that only virtual storage was fragmented, not real storage. I believe I remember running 8MB
    of VS on a 370/168 with 3MB real storage.

    For OS/360 and OS/VSx and later, there is TSO. For real mode OS/360, TSO was complicated by the inability to move a program once it started, as programs could keep addresses (pointers). So, virtual storage was a big win for TSO.

    CMS goes with VM, and yes also allows for time-shared use.

    But yes, the larger systems ran more than one program (task) at a time,
    which allowed another program to run while one was doing I/O, or otherwise.

    Mostly this was done on other larger systems, such as DEC's PDP-10 and VAX systems. It is the total address space of all programs that is bigger than physical memory.

    But okay, Unix systems in the late 1980's, such as Suns, were often enough
    used by only one person. And for those, virtual memory might have been
    used to allow larger programs, than physical memory.

    But otherwise, it was mostly not until virtual storage for 80286 based
    personal computers. I had OS/2 v1.0 running on an AT clone in 1990, when
    most were running MS-DOS with 640K real memory. I think I had 5MB
    on my first OS/2 system. (There was also Xenix, and some others.)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Themos Tsikas@21:1/5 to FortranFan on Fri Jul 9 02:53:05 2021
    On Thursday, 8 July 2021 at 01:22:03 UTC+1, FortranFan wrote:

    Nice way to rationalize *whatever* might be going on that simply cannot be understood exactly but which makes Fortran move up the ranking!

    This graph at the same ranking site might also be revealing, suggesting whatever is going on might be fleeting:
    https://www.tiobe.com/tiobe-index/fortran/

    One thing younger languages don't have is a forum where 50 year old practices are endlessly debated.

    Themos Tsikas, NAG Ltd

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jos Bergervoet@21:1/5 to Robin Vowels on Fri Jul 9 12:41:37 2021
    On 21/07/09 3:59 AM, Robin Vowels wrote:
    On Friday, July 9, 2021 at 3:38:04 AM UTC+10, Jos Bergervoet wrote:
    On 21/07/08 6:25 AM, Robin Vowels wrote:
    On Thursday, July 8, 2021 at 7:36:03 AM UTC+10, Jos Bergervoet wrote:
    On 21/07/07 5:28 PM, Rudi Gaelzer wrote:
    On April last, it was reported that Fortran had returned to the top 20 languages, according to the TIOBE index.
    Now, the July report shows that Fortran climbed to the 14th. position: https://www.tiobe.com/tiobe-index/
    and still going up; possibly to the 13th. or 12th. position in the next report.
    I think this is auspicious news.
    What do you think were the causes of this renewed raise on the interest of Fortran?
    People start to realize there aren't many languages that have:

    1) A language evolution based on steady, backward-compatible changes.
    .
    A number of old features are no longer standard and have been deleted
    or are due to be deleted.
    A number of old "features" that continue to be used, were never standard.
    .
    In the first decades of its life, FORTRAN fooled around just like
    those young languages we see around us now! But with age comes
    responsibility, and that's probably what we're seeing here.
    .
    2) An unambiguous language definition, maintained by a standardization >>>> committee.
    .
    Ambiguous definitions arise in the case of certain COMPLEX constructs
    that are error-prone.
    .
    The KIND specification is ambiguous, and can catch anyone.
    .
    If any ambiguities still pop up then at least an 'interpretation' of
    the rules can be given by the standardization body to resolve the
    issue.
    .
    The ambiguities cited (COMPLEX, kind values) cannot be "resolved"
    by an "interpretation". Those are deficiencies in the design.
    30 years have now elapsed since these design flaws were introduced
    and still these flaws have not been fixed.
    .
    3) A high enough age to be reasonably complete despite the very
    slow progress guaranteed by points 1) and 2).
    4) A large code base and libraries for most things you need.
    5) A compiler included in the public domain gcc compiler suite.
    6) An excellent reputation for execution speed.
    7) Parallel programming as integrated part of the language.

    It is understandable that this took some time to sink in, since some of >>>> these things are a bit paradoxical. Especially the fact that Fortran
    is as advanced as it is precisely because it is as old as it is.

    But I think the list shows that the TIOBE ranking is well-deserved.
    .
    People start to realize there aren't many languages that have:
    .
    One such language is PL/I, which was introduced as an an improved
    FORTRAN -- and a vast improvement it was! (and still is).
    .
    But PL/I doesn't have points 4), 5) and 7), to name a few.
    .
    What? You think that PL/I does not lave a large code base and libraries
    for most things that you need?

    Less so than Fortran.

    What? You think that PL/I does not have a public domain compiler?

    The claim was about the public-domain gcc compiler suite. You can
    choose between C, C++ and Fortran.

    What? You think that PLI has no parallel programming? PL/I has
    had this since PL/I-F in 1966.

    How are co-arrays defined and how are the images synchronized? Is that
    in the official PL/I language standard?

    What else do you think that PL/I does not have?
    Well, it does not have ambiguous definitions.

    I'm quite sure PL/I is a good language and was better than Fortran at
    the time of introduction. Ans so was Algol68. But my list contains
    things that aren't necessarily determined by those facts. Even if
    you think that Fortran as a language is not the very best, you can
    still agree that it is quite good and also has a few circumstantial
    advantages, as mentioned in the list.

    --
    Jos

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rudi Gaelzer@21:1/5 to All on Fri Jul 9 05:04:10 2021
    I'm somewhat delighted by the discussion sparked by my original post.
    One aspect that I originally wanted to incite a debate about is regarded to the different rankings of popularity/usage of programming languages that one can find on the net.
    It was pointed out that the PYPL index (https://pypl.github.io/PYPL.html) would be a more trustworthy indicator of the current popularity of a given language. And indeed, in the PYPL index, Fortran is not listed among the top 20.
    In fact, the TIOBE and PYPL indices show quite disparate results, with languages poorly-ranked in the first appearing at the tops in the latter (Rust and Julia are examples).
    IMVHO (very humble opinion), what happens with the PYPL index is that they rank the languages according to the number of searches for the language's tutorial. That seems to favor those languages that have "standard" tutorials that can be easily found,
    such as:
    https://docs.python.org/3/tutorial/
    https://en.cppreference.com/w/
    https://julialang.org/learning/tutorials/
    https://www.rust-lang.org/learn
    just to name a few.
    Some of those tutorials were built by the same maintainers of the "official" website of the languages, usually created by the community of developers/users. It seems to me that Fortran is lacking in this aspect. I have no knowledge of a comprehensive
    tutorial of Fortran, apart from some third-party iniciatives (such as tutorialspoint and Fortran Wiki).
    IMVVHO, it should fall on the shoulders of the ISO/WG5 committee the task of creating and maintaining such a service, or to delegate the task to a group of maintainers and then provide validation for it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to All on Fri Jul 9 18:20:46 2021
    On 7/8/2021 8:21 PM, gah4 wrote:
    On Thursday, July 8, 2021 at 1:45:01 PM UTC-7, Lynn McGuire wrote:

    (snip)

    All Fortran code developed on Univac 1108s or IBM mainframes or using
    the Unix F77 compiler had automatic zero initialization as a feature.
    Most Fortran programmers never realized that local variables should be
    initialized until it was too late.

    IBM mainframes didn't (and don't) automatically zero initialization, but
    it can be done. One I knew (OS/360 days) initialized to X'81'.

    It is complicated, though. Such data isn't initialized at all by the compiler,
    but left has 'holes' in the object program. Each record (card) of the object program has a start address and length. None cover uninitialized data.

    The linkage editor then takes object programs and combines them.
    It likes to write out larger records, and so has to fill-in smaller such blocks. Older ones left whatever was in its own memory space.
    Later ones would initialize that space.

    But larger ones are not written to the load module, but, as with the
    object program are left out. In this case, it is whatever is in memory
    before load module fetch. Part of that is the initiator that opens
    data sets, and otherwise gets things ready, and then reads in the
    actual load module records. So this also has to be changed to actually initialize Fortran variables. As noted, it can be done.

    That is all before MVS. OS/360 uses only real storage addresses.
    OS/VS1 and OS/VS2 use a single virtual address space with all
    programs in it. By the time of MVS, it is likely that security
    requirements disallowed one program's data from being seen by
    others, but not from itself.
    But note as above, there are two places that have to be changed.
    Even if the OS zeros all pages, it still reads in the load module which
    might have already initialized such blocks with whatever is left
    over in the linkage editor memory.

    Fortran E, G, H, and VS Fortran all used only static allocation.
    As well as I know, there is no IBM supplied Fortran 90 or
    later compiler for descendants of OS/360.

    We only ported to the IBM 370 and newer systems. I have no idea what
    the IBM 360 system was like.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to someone on Fri Jul 9 19:07:19 2021
    On Friday, July 9, 2021 at 3:42:04 AM UTC-7, Jos Bergervoet wrote:

    (snip, someone wrote)

    What? You think that PLI has no parallel programming? PL/I has
    had this since PL/I-F in 1966.

    How are co-arrays defined and how are the images synchronized? Is that
    in the official PL/I language standard?

    PL/I has multitasking. Not quite the same as multithreading.

    The usual use would be to start a subtask, and then some time later WAIT
    (that is the statement) for it to finish. There are EVENT variables, which correspond to OS/360 ECBs (event control blocks).

    I believe this is usually described as coarse grain multitasking, as
    opposed to the fine grain of multithreading.

    Maybe more obvious, it is also used for asynchronous I/O, which I believe Fortran now has.

    Among others, PL/I compilers generate not only reentrant routines
    that can be used for recursion, but also reentrant for multiple tasks
    at the same time. Among others, it complicates I/O, where different
    tasks have different I/O streams from the same code.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to All on Fri Jul 9 19:13:48 2021
    On Friday, July 9, 2021 at 4:20:49 PM UTC-7, Lynn McGuire wrote:

    (snip, I wrote)
    Fortran E, G, H, and VS Fortran all used only static allocation.
    As well as I know, there is no IBM supplied Fortran 90 or
    later compiler for descendants of OS/360.

    We only ported to the IBM 370 and newer systems. I have no idea what
    the IBM 360 system was like.

    The compilers were the same, though they were under continual evolution.

    As noted, though, it is mostly not the compiler, but the linkage editor and program fetch (loading programs into memory to execute them), and those
    may have changed along the way.

    One that I remember, I suspect from OS/360 days, was executing the linkage editor after a compilation failed. It then tried to read in the object program from a data set that was never written. It instead read whatever was in those disk blocks from the previous use. That was before people worried as much about data security. I suspect that in the early days of OS/360, programs could
    get data from other users left over in core. At some point, I suspect that had to change. But that doesn't mean you don't get your own data left in core.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Lynn McGuire on Fri Jul 9 21:11:00 2021
    On Saturday, July 10, 2021 at 9:20:49 AM UTC+10, Lynn McGuire wrote:
    On 7/8/2021 8:21 PM, gah4 wrote:
    On Thursday, July 8, 2021 at 1:45:01 PM UTC-7, Lynn McGuire wrote:

    (snip)

    All Fortran code developed on Univac 1108s or IBM mainframes or using
    the Unix F77 compiler had automatic zero initialization as a feature.
    Most Fortran programmers never realized that local variables should be
    initialized until it was too late.

    IBM mainframes didn't (and don't) automatically zero initialization, but
    it can be done. One I knew (OS/360 days) initialized to X'81'.

    It is complicated, though. Such data isn't initialized at all by the compiler,
    but left has 'holes' in the object program. Each record (card) of the object
    program has a start address and length. None cover uninitialized data.

    The linkage editor then takes object programs and combines them.
    It likes to write out larger records, and so has to fill-in smaller such blocks. Older ones left whatever was in its own memory space.
    Later ones would initialize that space.

    But larger ones are not written to the load module, but, as with the
    object program are left out. In this case, it is whatever is in memory before load module fetch. Part of that is the initiator that opens
    data sets, and otherwise gets things ready, and then reads in the
    actual load module records. So this also has to be changed to actually initialize Fortran variables. As noted, it can be done.

    That is all before MVS. OS/360 uses only real storage addresses.
    OS/VS1 and OS/VS2 use a single virtual address space with all
    programs in it. By the time of MVS, it is likely that security
    requirements disallowed one program's data from being seen by
    others, but not from itself.
    But note as above, there are two places that have to be changed.
    Even if the OS zeros all pages, it still reads in the load module which might have already initialized such blocks with whatever is left
    over in the linkage editor memory.

    Fortran E, G, H, and VS Fortran all used only static allocation.
    As well as I know, there is no IBM supplied Fortran 90 or
    later compiler for descendants of OS/360.
    .
    We only ported to the IBM 370 and newer systems. I have no idea what
    the IBM 360 system was like.
    .
    Like the /370, only slower.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Robin Vowels on Sat Jul 10 01:00:22 2021
    On 7/9/2021 11:11 PM, Robin Vowels wrote:
    On Saturday, July 10, 2021 at 9:20:49 AM UTC+10, Lynn McGuire wrote:
    On 7/8/2021 8:21 PM, gah4 wrote:
    On Thursday, July 8, 2021 at 1:45:01 PM UTC-7, Lynn McGuire wrote:

    (snip)

    All Fortran code developed on Univac 1108s or IBM mainframes or using
    the Unix F77 compiler had automatic zero initialization as a feature.
    Most Fortran programmers never realized that local variables should be >>>> initialized until it was too late.

    IBM mainframes didn't (and don't) automatically zero initialization, but >>> it can be done. One I knew (OS/360 days) initialized to X'81'.

    It is complicated, though. Such data isn't initialized at all by the compiler,
    but left has 'holes' in the object program. Each record (card) of the object
    program has a start address and length. None cover uninitialized data.

    The linkage editor then takes object programs and combines them.
    It likes to write out larger records, and so has to fill-in smaller such >>> blocks. Older ones left whatever was in its own memory space.
    Later ones would initialize that space.

    But larger ones are not written to the load module, but, as with the
    object program are left out. In this case, it is whatever is in memory
    before load module fetch. Part of that is the initiator that opens
    data sets, and otherwise gets things ready, and then reads in the
    actual load module records. So this also has to be changed to actually
    initialize Fortran variables. As noted, it can be done.

    That is all before MVS. OS/360 uses only real storage addresses.
    OS/VS1 and OS/VS2 use a single virtual address space with all
    programs in it. By the time of MVS, it is likely that security
    requirements disallowed one program's data from being seen by
    others, but not from itself.
    But note as above, there are two places that have to be changed.
    Even if the OS zeros all pages, it still reads in the load module which
    might have already initialized such blocks with whatever is left
    over in the linkage editor memory.

    Fortran E, G, H, and VS Fortran all used only static allocation.
    As well as I know, there is no IBM supplied Fortran 90 or
    later compiler for descendants of OS/360.
    .
    We only ported to the IBM 370 and newer systems. I have no idea what
    the IBM 360 system was like.
    .
    Like the /370, only slower.

    We had considerable problems porting to the IBM 370. It was our first 8
    bit machine. Before, we developed on the Univac 1108 (36 bit) and
    ported to the CDC 7600 (60 bit), both 6 bit machines. Since the Univac
    1108 supported six characters per word, we had assumed that would work everywhere. We had to rewrite all of our statements storing 6HXXXXXX
    into an integer to storing 4HXXXX and 2HXX in two integers. Quite painful.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Lynn McGuire on Sat Jul 10 01:29:39 2021
    On Friday, July 9, 2021 at 11:00:27 PM UTC-7, Lynn McGuire wrote:

    (snip)

    We had considerable problems porting to the IBM 370. It was our first 8
    bit machine. Before, we developed on the Univac 1108 (36 bit) and
    ported to the CDC 7600 (60 bit), both 6 bit machines. Since the Univac
    1108 supported six characters per word, we had assumed that would work everywhere. We had to rewrite all of our statements storing 6HXXXXXX
    into an integer to storing 4HXXXX and 2HXX in two integers. Quite painful.

    I was last week working with Spice 2g6, the last of the Fortran Spice programs.

    I believe it was most often run on VAX 40 or so years ago.
    It uses double precision for most of its data (except COMPLEX), and the double precision includes character data of up to 8 characters. (All names are only significant to the first 8 characters.)

    That is a little tricky, as not all machines accurately compare floating point data with characters in them. In most places, it just compares them, but
    in some it uses a subroutine to do the comparison. The subroutine in
    the version I have just compares them, but it could be replaced with a
    fancier one.

    There is also a subroutine to copy characters from one to another, which (usually) has double precision arguments, but the dummy variables
    are arrays of bytes. It would have used LOGICAL*1 for the IBM/370 version,
    and maybe BYTE for the VAX version, but seems to work with INTEGER(1)
    on gfortran. It might be that I am the first to compile it in 28 years.

    I believe that the IBM/370 can reliably compare character data in REAL*8 variables. Also, S/370 doesn't normalize on assignment, which would
    destroy character data. Spice has many 8H constants. For S/370 and VAX,
    you could even use COMPLEX*16 for 16 characters.

    One that I haven't figure out yet, gfortran allows initializing double precision
    variables with 8H constants, but not apostrophe delimited constants.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to All on Sat Jul 10 03:44:43 2021
    On Saturday, July 10, 2021 at 6:29:41 PM UTC+10, gah4 wrote:
    On Friday, July 9, 2021 at 11:00:27 PM UTC-7, Lynn McGuire wrote:

    (snip)
    We had considerable problems porting to the IBM 370. It was our first 8
    bit machine. Before, we developed on the Univac 1108 (36 bit) and
    ported to the CDC 7600 (60 bit), both 6 bit machines. Since the Univac
    1108 supported six characters per word, we had assumed that would work everywhere. We had to rewrite all of our statements storing 6HXXXXXX
    into an integer to storing 4HXXXX and 2HXX in two integers. Quite painful.
    I was last week working with Spice 2g6, the last of the Fortran Spice programs.

    I believe it was most often run on VAX 40 or so years ago.
    It uses double precision for most of its data (except COMPLEX), and the double
    precision includes character data of up to 8 characters. (All names are only significant to the first 8 characters.)

    That is a little tricky, as not all machines accurately compare floating point
    data with characters in them. In most places, it just compares them, but
    in some it uses a subroutine to do the comparison. The subroutine in
    the version I have just compares them, but it could be replaced with a fancier one.

    There is also a subroutine to copy characters from one to another, which (usually) has double precision arguments, but the dummy variables
    are arrays of bytes. It would have used LOGICAL*1 for the IBM/370 version, and maybe BYTE for the VAX version, but seems to work with INTEGER(1)
    on gfortran. It might be that I am the first to compile it in 28 years.

    I believe that the IBM/370 can reliably compare character data in REAL*8 variables.
    .
    CHARACTER variables have been available since FORTRAN 77,
    and in PL/I since 1966.
    .
    Also, S/370 doesn't normalize on assignment, which would
    destroy character data. Spice has many 8H constants. For S/370 and VAX,
    you could even use COMPLEX*16 for 16 characters.

    One that I haven't figure out yet, gfortran allows initializing double precision
    variables with 8H constants, but not apostrophe delimited constants.
    .
    Is this something important?, since for 40+ years, FORTRAN has had
    CHARACTER variables.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jos Bergervoet@21:1/5 to All on Sat Jul 10 13:56:08 2021
    On 21/07/10 4:07 AM, gah4 wrote:
    On Friday, July 9, 2021 at 3:42:04 AM UTC-7, Jos Bergervoet wrote:

    (snip, someone wrote)

    What? You think that PLI has no parallel programming? PL/I has
    had this since PL/I-F in 1966.

    How are co-arrays defined and how are the images synchronized? Is that
    in the official PL/I language standard?

    PL/I has multitasking. Not quite the same as multithreading.

    The usual use would be to start a subtask, and then some time later WAIT (that is the statement) for it to finish. There are EVENT variables, which correspond to OS/360 ECBs (event control blocks).

    That was also possible in Algol68 in those times. The "parallel clause"
    would start the tasks:
    par( do_this, do_that, ... );
    and then there was the "semaphore" type to make tasks aware of each
    other's state and to wait if needed.


    I believe this is usually described as coarse grain multitasking, as
    opposed to the fine grain of multithreading.

    Maybe more obvious, it is also used for asynchronous I/O, which I believe Fortran now has.

    Among others, PL/I compilers generate not only reentrant routines
    that can be used for recursion, but also reentrant for multiple tasks
    at the same time. Among others, it complicates I/O, where different
    tasks have different I/O streams from the same code.

    I/O is just one thing (and probably not dominant in the time
    consumption for complicated numerical problems).

    But how is the shared memory being handled? There you have the
    same problem. If the user has to do that "by hand" for all shared
    variables (using the semaphores and similar constructs) then it
    is not a solution that is built into the language, as I meant it.
    Only the tools to create a solution by hand are then built into
    the language.

    --
    Jos

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to All on Sat Jul 10 12:35:34 2021
    On Saturday, July 10, 2021 at 3:44:45 AM UTC-7, Robin Vowels wrote:

    (snip, I wrote)
    One that I haven't figure out yet, gfortran allows initializing double precision
    variables with 8H constants, but not apostrophe delimited constants.

    Is this something important?, since for 40+ years, FORTRAN has had
    CHARACTER variables.

    And some programs are older than that.

    Spice2 is 1975, following Spice1 earlier.

    As well as I know, descendants of ECAP originally written
    in Fortran II.

    The ECAP that I have came from an IBM 1130, which uses a subset
    version of Fortran IV. No logical variables or logical IF. Only five character variable names. It seems that they took all the six character names
    (from an earlier compiler), removed the middle two letters and replaced
    them with Z. There are some WRITE statement that give the name of the
    variable that they are writing out. I believe it goes back to about 1963.
    For ECAP, all language keywords are recognized by only the first two characters, and most programs abbreviate them.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to All on Sat Jul 10 16:03:35 2021
    On 7/10/2021 3:29 AM, gah4 wrote:
    On Friday, July 9, 2021 at 11:00:27 PM UTC-7, Lynn McGuire wrote:

    (snip)

    We had considerable problems porting to the IBM 370. It was our first 8
    bit machine. Before, we developed on the Univac 1108 (36 bit) and
    ported to the CDC 7600 (60 bit), both 6 bit machines. Since the Univac
    1108 supported six characters per word, we had assumed that would work
    everywhere. We had to rewrite all of our statements storing 6HXXXXXX
    into an integer to storing 4HXXXX and 2HXX in two integers. Quite painful.

    I was last week working with Spice 2g6, the last of the Fortran Spice programs.

    I believe it was most often run on VAX 40 or so years ago.
    It uses double precision for most of its data (except COMPLEX), and the double
    precision includes character data of up to 8 characters. (All names are only significant to the first 8 characters.)

    That is a little tricky, as not all machines accurately compare floating point
    data with characters in them. In most places, it just compares them, but
    in some it uses a subroutine to do the comparison. The subroutine in
    the version I have just compares them, but it could be replaced with a fancier one.

    There is also a subroutine to copy characters from one to another, which (usually) has double precision arguments, but the dummy variables
    are arrays of bytes. It would have used LOGICAL*1 for the IBM/370 version, and maybe BYTE for the VAX version, but seems to work with INTEGER(1)
    on gfortran. It might be that I am the first to compile it in 28 years.

    I believe that the IBM/370 can reliably compare character data in REAL*8 variables. Also, S/370 doesn't normalize on assignment, which would
    destroy character data. Spice has many 8H constants. For S/370 and VAX,
    you could even use COMPLEX*16 for 16 characters.

    One that I haven't figure out yet, gfortran allows initializing double precision
    variables with 8H constants, but not apostrophe delimited constants.

    There was no double precision or character data in 1975 when we did our
    first port to the IBM 370.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Lynn McGuire on Sat Jul 10 16:32:35 2021
    On Saturday, July 10, 2021 at 2:03:42 PM UTC-7, Lynn McGuire wrote:

    (snip)

    There was no double precision or character data in 1975 when we did our
    first port to the IBM 370.

    CHARACTER didn't come until Fortran 77, or VS Fortran for the 370.

    But double precision, including its use for A8 format and Hollerith constants goes back to sometime in the Fortran II days, and definitely in all the 360
    and 370 compilers. Many programs written for single precision on 36 but predecessors, needed double precision for S/360.

    A small number of systems would normalize, or otherwise change the value
    of floating point variables, but S/370 is fine. COMPLEX works, too.

    If you want to play with the bits, shift and mask them, then it is harder.
    As above, Spice uses a subroutine to do all the moving of characters,
    which could be in assembly if it can't be done in Fortran. But on S/370
    it can be done with LOGICAL*1 and EQUIVALENCE.

    Spice does all the comparisons in double precision. For individual
    characters, it fills a variable with blanks (from an H constant), replaces
    the leftmost characters (with a subroutine) and the compares to
    an H constant. Doing the move in one subroutine localizes the
    machine dependence to one place.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to All on Sat Jul 10 19:18:39 2021
    On 7/10/2021 6:32 PM, gah4 wrote:
    On Saturday, July 10, 2021 at 2:03:42 PM UTC-7, Lynn McGuire wrote:

    (snip)

    There was no double precision or character data in 1975 when we did our
    first port to the IBM 370.

    CHARACTER didn't come until Fortran 77, or VS Fortran for the 370.

    But double precision, including its use for A8 format and Hollerith constants goes back to sometime in the Fortran II days, and definitely in all the 360 and 370 compilers. Many programs written for single precision on 36 but predecessors, needed double precision for S/360.

    A small number of systems would normalize, or otherwise change the value
    of floating point variables, but S/370 is fine. COMPLEX works, too.

    If you want to play with the bits, shift and mask them, then it is harder.
    As above, Spice uses a subroutine to do all the moving of characters,
    which could be in assembly if it can't be done in Fortran. But on S/370
    it can be done with LOGICAL*1 and EQUIVALENCE.

    Spice does all the comparisons in double precision. For individual characters, it fills a variable with blanks (from an H constant), replaces the leftmost characters (with a subroutine) and the compares to
    an H constant. Doing the move in one subroutine localizes the
    machine dependence to one place.

    If so, I am not sure that the Univac 1108 and CDC 7600 supported double precision. Of course, we moved to a Prime 450 (32 bit single precision)
    in 1978 for our development. But, we supported our customers on the
    Univac 1108 until 1982 or 1983. And we were up against the linker limit
    on the Univac 1108 so we would not have had the room to convert from
    single to double. We did convert to double precision around 2000,
    solved a lot of precision problems we had and brought a few more of its own.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From JCampbell@21:1/5 to All on Sat Jul 10 21:08:08 2021
    On Sunday, July 11, 2021 at 5:35:36 AM UTC+10, gah4 wrote:
    On Saturday, July 10, 2021 at 3:44:45 AM UTC-7, Robin Vowels wrote:

    (snip, I wrote)
    One that I haven't figure out yet, gfortran allows initializing double precision
    variables with 8H constants, but not apostrophe delimited constants.
    Is this something important?, since for 40+ years, FORTRAN has had CHARACTER variables.
    And some programs are older than that.

    Spice2 is 1975, following Spice1 earlier.

    As well as I know, descendants of ECAP originally written
    in Fortran II.

    The ECAP that I have came from an IBM 1130, which uses a subset
    version of Fortran IV. No logical variables or logical IF. Only five character
    variable names. It seems that they took all the six character names
    (from an earlier compiler), removed the middle two letters and replaced
    them with Z. There are some WRITE statement that give the name of the variable that they are writing out. I believe it goes back to about 1963.
    For ECAP, all language keywords are recognized by only the first two characters, and most programs abbreviate them.
    I am puzzled why you have held onto storing character data in non-character variables or arrays for so long. Is this a personal challenge?
    In the early 80's I converted a number of pre-F77 Fortran codes for both character and generic intrinsics.
    Plan out the changes by defining new data structures and they became fairly easy to implement and test.
    Now, with F90's ALLOCATE and derived types, this task is never difficult and the sooner these data structures were more clearly described, the easier it was for further development.
    The most annoying part of this update was the lack of documentation of the compiler and hardware architecture used for initial development.
    Many programs were moved between CDC and Vax/Pr1me and then later onto Apollo/Sun and PC. Now, for me at Ryzen it has been quite a journey.

    Back to the OP, my focus in recent years has been OpenMP, which provides significant gains. Fortran does this very well here but outside the standard. Does this feature in the TIOBE space?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to Lynn McGuire on Sat Jul 10 21:03:34 2021
    On Sunday, July 11, 2021 at 7:03:42 AM UTC+10, Lynn McGuire wrote:
    On 7/10/2021 3:29 AM, gah4 wrote:
    On Friday, July 9, 2021 at 11:00:27 PM UTC-7, Lynn McGuire wrote:

    (snip)

    We had considerable problems porting to the IBM 370. It was our first 8
    bit machine. Before, we developed on the Univac 1108 (36 bit) and
    ported to the CDC 7600 (60 bit), both 6 bit machines. Since the Univac
    1108 supported six characters per word, we had assumed that would work
    everywhere. We had to rewrite all of our statements storing 6HXXXXXX
    into an integer to storing 4HXXXX and 2HXX in two integers. Quite painful.

    I was last week working with Spice 2g6, the last of the Fortran Spice programs.

    I believe it was most often run on VAX 40 or so years ago.
    It uses double precision for most of its data (except COMPLEX), and the double
    precision includes character data of up to 8 characters. (All names are only
    significant to the first 8 characters.)

    That is a little tricky, as not all machines accurately compare floating point
    data with characters in them. In most places, it just compares them, but
    in some it uses a subroutine to do the comparison. The subroutine in
    the version I have just compares them, but it could be replaced with a fancier one.

    There is also a subroutine to copy characters from one to another, which (usually) has double precision arguments, but the dummy variables
    are arrays of bytes. It would have used LOGICAL*1 for the IBM/370 version, and maybe BYTE for the VAX version, but seems to work with INTEGER(1)
    on gfortran. It might be that I am the first to compile it in 28 years.

    I believe that the IBM/370 can reliably compare character data in REAL*8 variables. Also, S/370 doesn't normalize on assignment, which would
    destroy character data. Spice has many 8H constants. For S/370 and VAX,
    you could even use COMPLEX*16 for 16 characters.

    One that I haven't figure out yet, gfortran allows initializing double precision
    variables with 8H constants, but not apostrophe delimited constants.
    .
    There was no double precision or character data in 1975 when we did our
    first port to the IBM 370.
    .
    DOUBLE PRECISION has been available on IBM mainframes since
    at least the IBM 360, and was therefore available on the IBM 370.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Koenig@21:1/5 to gah4@u.washington.edu on Sun Jul 11 10:21:14 2021
    gah4 <gah4@u.washington.edu> schrieb:
    On Saturday, July 10, 2021 at 2:03:42 PM UTC-7, Lynn McGuire wrote:

    (snip)

    There was no double precision or character data in 1975 when we did our
    first port to the IBM 370.

    CHARACTER didn't come until Fortran 77, or VS Fortran for the 370.

    But double precision, including its use for A8 format and Hollerith constants goes back to sometime in the Fortran II days, and definitely in all the 360 and 370 compilers. Many programs written for single precision on 36 but predecessors, needed double precision for S/360.

    ... as a result of a rather bad decision on floating point format.

    Henry S. Warren Junior had a section on that decision in "Hacker's
    Delight", and it wasn't positive.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gary Scott@21:1/5 to JCampbell on Sun Jul 11 08:18:45 2021
    On 7/10/2021 11:08 PM, JCampbell wrote:
    On Sunday, July 11, 2021 at 5:35:36 AM UTC+10, gah4 wrote:
    On Saturday, July 10, 2021 at 3:44:45 AM UTC-7, Robin Vowels wrote:

    (snip, I wrote)
    One that I haven't figure out yet, gfortran allows initializing double precision
    variables with 8H constants, but not apostrophe delimited constants.
    Is this something important?, since for 40+ years, FORTRAN has had
    CHARACTER variables.
    And some programs are older than that.

    Spice2 is 1975, following Spice1 earlier.

    As well as I know, descendants of ECAP originally written
    in Fortran II.

    The ECAP that I have came from an IBM 1130, which uses a subset
    version of Fortran IV. No logical variables or logical IF. Only five character
    variable names. It seems that they took all the six character names
    (from an earlier compiler), removed the middle two letters and replaced
    them with Z. There are some WRITE statement that give the name of the
    variable that they are writing out. I believe it goes back to about 1963.
    For ECAP, all language keywords are recognized by only the first two
    characters, and most programs abbreviate them.
    I am puzzled why you have held onto storing character data in non-character variables or arrays for so long. Is this a personal challenge?

    In my case, character data was sometimes stored in integers. The main
    reason for continuing to use them is because some of the operating
    system system services were written with the arguments storing character
    data in integers...so, not much choice

    In the early 80's I converted a number of pre-F77 Fortran codes for both character and generic intrinsics.
    Plan out the changes by defining new data structures and they became fairly easy to implement and test.
    Now, with F90's ALLOCATE and derived types, this task is never difficult and the sooner these data structures were more clearly described, the easier it was for further development.
    The most annoying part of this update was the lack of documentation of the compiler and hardware architecture used for initial development.
    Many programs were moved between CDC and Vax/Pr1me and then later onto Apollo/Sun and PC. Now, for me at Ryzen it has been quite a journey.

    Back to the OP, my focus in recent years has been OpenMP, which provides significant gains. Fortran does this very well here but outside the standard. Does this feature in the TIOBE space?


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ron Shepard@21:1/5 to Lynn McGuire on Sun Jul 11 12:00:40 2021
    On 7/10/21 7:18 PM, Lynn McGuire wrote:
    If so, I am not sure that the Univac 1108 and CDC 7600 supported double precision.

    The univac 1108 did have double precision. Since it was a 36-bit word
    machine, double precision meant 72-bits. During the time you are talking
    about, 1975 to 1980, I also used the univac 1108 and the Decsystem-20.
    Both had 36-bit words and 72-bit double precision, but their formats
    were different. For characters, the univac used six 6-bit characters per
    word, while the Dec used five 7-bit ascii characters per word (with one
    bit left over, which was often used for something on those
    memory-limited machines). The machines I used had 65k and 128k words of
    memory, so we were always pushing against memory limits, packing groups
    of small integers into the words, using any insignificant bits in
    floating point words for various purposes (small offsets, logical flags,
    etc.), reusing common block memory for unrelated purposes, and so on.
    Despite all that, it was possible to write code that compiled and ran
    correctly on both machines. I mostly ported code from IBM and CDC
    machines at that time, not to them, but I did run on a few CDC 6400 and
    6600 machines at that time too. When you are in that situation, you find
    ways to write code in portable ways, code that did not always conform to
    the standard. Using real*8 declarations rather than real/double
    precision was one of those tricks -- portable but nonstandard.

    Speaking of the univac machine, it had an odd way to set and mask bits.
    In addition to the usual shift/and/or functions, there were two compiler functions, fld() and sfld() if I remember correctly, for reading and
    setting bits. The odd thing was that they could appear on either the
    left or the right side of a statement. I remember seeing the MIL-STD
    function mvbits() right after the f77 standard was adopted, and I
    thought it was similar to those old univac functions I had used years
    earlier, although it was only allowed on the right side of expressions.

    Of course, we programmers were all looking forward to a fortran revision
    in 1980 or so that would bring all of that MIL-STD stuff into the
    standard. In fact, it would take almost 15 years for that to happen,
    which is one reason why fortran lost so much ground to the lesser
    languages during the 1980s, and why the fortran ranking in the TIOBE
    index are being discussed even now 40 years later.

    $.02 -Ron Shepard

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Lynn McGuire on Sun Jul 11 12:38:13 2021
    On Saturday, July 10, 2021 at 5:18:44 PM UTC-7, Lynn McGuire wrote:

    (snip)

    If so, I am not sure that the Univac 1108 and CDC 7600 supported double precision. Of course, we moved to a Prime 450 (32 bit single precision)
    in 1978 for our development.

    The standard required it, so everyone had it. But sometimes in software,
    and much slower than single precision hardware.

    That was especially true for CDC, where 60 bits was more like other's
    double precision.

    DEC had two forms for the PDP-10, one in software for the KA-10,
    and a different one in hardware for later models.

    But in the case of character data, it is just a place to put bits.
    Though in the case of A format values, integer or real, (or anything
    else), the standard doesn't say much about even assigning them.
    Not all bits are guaranteed to copy in an assignment, or compare
    in a comparison. But usually they do.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Robin Vowels on Sun Jul 11 15:51:39 2021
    On 7/10/2021 11:03 PM, Robin Vowels wrote:
    On Sunday, July 11, 2021 at 7:03:42 AM UTC+10, Lynn McGuire wrote:
    On 7/10/2021 3:29 AM, gah4 wrote:
    On Friday, July 9, 2021 at 11:00:27 PM UTC-7, Lynn McGuire wrote:

    (snip)

    We had considerable problems porting to the IBM 370. It was our first 8 >>>> bit machine. Before, we developed on the Univac 1108 (36 bit) and
    ported to the CDC 7600 (60 bit), both 6 bit machines. Since the Univac >>>> 1108 supported six characters per word, we had assumed that would work >>>> everywhere. We had to rewrite all of our statements storing 6HXXXXXX
    into an integer to storing 4HXXXX and 2HXX in two integers. Quite painful. >>>
    I was last week working with Spice 2g6, the last of the Fortran Spice programs.

    I believe it was most often run on VAX 40 or so years ago.
    It uses double precision for most of its data (except COMPLEX), and the double
    precision includes character data of up to 8 characters. (All names are only
    significant to the first 8 characters.)

    That is a little tricky, as not all machines accurately compare floating point
    data with characters in them. In most places, it just compares them, but >>> in some it uses a subroutine to do the comparison. The subroutine in
    the version I have just compares them, but it could be replaced with a
    fancier one.

    There is also a subroutine to copy characters from one to another, which >>> (usually) has double precision arguments, but the dummy variables
    are arrays of bytes. It would have used LOGICAL*1 for the IBM/370 version, >>> and maybe BYTE for the VAX version, but seems to work with INTEGER(1)
    on gfortran. It might be that I am the first to compile it in 28 years.

    I believe that the IBM/370 can reliably compare character data in REAL*8 >>> variables. Also, S/370 doesn't normalize on assignment, which would
    destroy character data. Spice has many 8H constants. For S/370 and VAX,
    you could even use COMPLEX*16 for 16 characters.

    One that I haven't figure out yet, gfortran allows initializing double precision
    variables with 8H constants, but not apostrophe delimited constants.
    .
    There was no double precision or character data in 1975 when we did our
    first port to the IBM 370.
    .
    DOUBLE PRECISION has been available on IBM mainframes since
    at least the IBM 360, and was therefore available on the IBM 370
    We could not use it anyway. We were at the linker limit on the Univac
    1108 and playing all kinds to keep from hitting it.

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dpb@21:1/5 to All on Sun Jul 11 16:56:31 2021
    On 7/11/2021 2:38 PM, gah4 wrote:
    On Saturday, July 10, 2021 at 5:18:44 PM UTC-7, Lynn McGuire wrote:

    (snip)

    If so, I am not sure that the Univac 1108 and CDC 7600 supported double
    precision. Of course, we moved to a Prime 450 (32 bit single precision)
    in 1978 for our development.

    The standard required it, so everyone had it. But sometimes in software,
    and much slower than single precision hardware.

    That was especially true for CDC, where 60 bits was more like other's
    double precision.

    DEC had two forms for the PDP-10, one in software for the KA-10,
    and a different one in hardware for later models.

    ...

    CDC 60-bit floating-point was 1 sign bit and an 11-bit exponent
    including bias, with a 48-bit bit-normalized mantissa.

    The CDC 6000/7000 instruction set included double precision instructions
    for addition, subtraction, and multiplication. They operated on 60-bit quantities, just as single precision numbers.

    Double precision numbers were just two single precision numbers
    back-to-back, with the second exponent being essentially redundant. It
    was a waste of 12 bits, but you still got 96 bits of precision.

    --

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to dpb on Sun Jul 11 19:05:50 2021
    On Sunday, July 11, 2021 at 2:56:35 PM UTC-7, dpb wrote:

    (snip)
    CDC 60-bit floating-point was 1 sign bit and an 11-bit exponent
    including bias, with a 48-bit bit-normalized mantissa.

    I thought CDC was one where if the value is an integer in the appropriate range, it stores it unnormalized, and with zero exponent, such that it has
    the integer value. Saves the need for separate integer instructions.

    The CDC 6000/7000 instruction set included double precision instructions
    for addition, subtraction, and multiplication. They operated on 60-bit quantities, just as single precision numbers.

    Double precision numbers were just two single precision numbers
    back-to-back, with the second exponent being essentially redundant. It
    was a waste of 12 bits, but you still got 96 bits of precision.

    Yes, that is what IBM S/370 does with extended (quad) precision.
    It makes it easier to do in software.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to All on Sun Jul 11 19:47:07 2021
    On Monday, July 12, 2021 at 12:05:51 PM UTC+10, gah4 wrote:
    On Sunday, July 11, 2021 at 2:56:35 PM UTC-7, dpb wrote:

    (snip)
    CDC 60-bit floating-point was 1 sign bit and an 11-bit exponent
    including bias, with a 48-bit bit-normalized mantissa.
    I thought CDC was one where if the value is an integer in the appropriate range, it stores it unnormalized, and with zero exponent, such that it has the integer value. Saves the need for separate integer instructions.
    .
    60-bit integers are 60-bit integers.
    All 60 bits of an integer were used for storing an integer.
    Where the machine was deficient was in an integer multiply instruction.
    If the floating-point multiply instruction saw that the upper 12 bits
    as being zero or all ones, it did an integer multiplication,
    otherwise it did a floating-point multiplication.
    So, if an integer drifted into the high 12 bits, "Integer multiply"
    gave garbage.
    .
    The CDC 6000/7000 instruction set included double precision instructions for addition, subtraction, and multiplication. They operated on 60-bit quantities, just as single precision numbers.

    Double precision numbers were just two single precision numbers back-to-back, with the second exponent being essentially redundant. It
    was a waste of 12 bits, but you still got 96 bits of precision.
    Yes, that is what IBM S/370 does with extended (quad) precision.
    It makes it easier to do in software.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Robin Vowels on Sun Jul 11 21:02:41 2021
    On Sunday, July 11, 2021 at 7:47:09 PM UTC-7, Robin Vowels wrote:

    (snip)
    60-bit integers are 60-bit integers.
    All 60 bits of an integer were used for storing an integer.
    Where the machine was deficient was in an integer multiply instruction.
    If the floating-point multiply instruction saw that the upper 12 bits
    as being zero or all ones, it did an integer multiplication,
    otherwise it did a floating-point multiplication.
    So, if an integer drifted into the high 12 bits, "Integer multiply"
    gave garbage.

    I believe that isn't the right description for what it does.

    But yes, there are 60 bit integer add/subtract.

    When it normalizes numbers, it prefers an exponent of zero, and the binary point to the right of the LSB. It doesn't "check" for an integer, but it happens
    naturally with the floating point format. And if a floating point multiply gives
    an integer result that fits in the 48 bits, it will give the right integer result.

    And if integer multiply is too big, then it gives the proper floating point result.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to All on Tue Jul 13 10:49:57 2021
    On Monday, July 12, 2021 at 2:02:42 PM UTC+10, gah4 wrote:
    On Sunday, July 11, 2021 at 7:47:09 PM UTC-7, Robin Vowels wrote:

    (snip)
    60-bit integers are 60-bit integers.
    All 60 bits of an integer were used for storing an integer.
    Where the machine was deficient was in an integer multiply instruction.
    If the floating-point multiply instruction saw that the upper 12 bits
    as being zero or all ones, it did an integer multiplication,
    otherwise it did a floating-point multiplication.
    So, if an integer drifted into the high 12 bits, "Integer multiply"
    gave garbage.
    .
    I believe that isn't the right description for what it does.

    But yes, there are 60 bit integer add/subtract.

    When it normalizes numbers, it prefers an exponent of zero, and the binary point to the right of the LSB. It doesn't "check" for an integer,
    .
    The manual explicitly states that the Integer Multiply instruction (IM)
    checks for zero (+ or -, i.e. all zeors or all ones) in the upper 12 bits
    of both 60-bit operands. It then performs an integer multiply. The instruction op code is the same as the floating-point multiply instruction, and the operation is performed by the floating-point hardware.
    .
    but it happens
    naturally with the floating point format. And if a floating point multiply gives
    an integer result that fits in the 48 bits, it will give the right integer result.

    And if integer multiply is too big, then it gives the proper floating point result.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robin Vowels@21:1/5 to All on Tue Jul 13 10:37:01 2021
    On Monday, July 12, 2021 at 2:02:42 PM UTC+10, gah4 wrote:
    On Sunday, July 11, 2021 at 7:47:09 PM UTC-7, Robin Vowels wrote:

    (snip)
    60-bit integers are 60-bit integers.
    All 60 bits of an integer were used for storing an integer.
    Where the machine was deficient was in an integer multiply instruction.
    If the floating-point multiply instruction saw that the upper 12 bits
    as being zero or all ones, it did an integer multiplication,
    otherwise it did a floating-point multiplication.
    So, if an integer drifted into the high 12 bits, "Integer multiply"
    gave garbage..
    .
    I believe that isn't the right description for what it does.

    But yes, there are 60 bit integer add/subtract.

    When it normalizes numbers, it prefers an exponent of zero, and the binary point to the right of the LSB. It doesn't "check" for an integer, but it happens
    naturally with the floating point format. And if a floating point multiply gives
    an integer result that fits in the 48 bits, it will give the right integer result.

    And if integer multiply is too big, then it gives the proper floating point result.
    .
    That's irrelevant.
    If you wrote and executed an integer multiply instruction, and the result happened to
    exceed 48 bits, the result was garbage (in terms of an expected integer result).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Robin Vowels on Tue Jul 13 16:37:01 2021
    On Tuesday, July 13, 2021 at 10:49:59 AM UTC-7, Robin Vowels wrote:

    (snip)
    The manual explicitly states that the Integer Multiply instruction (IM) checks for zero (+ or -, i.e. all zeors or all ones) in the upper 12 bits
    of both 60-bit operands. It then performs an integer multiply. The instruction
    op code is the same as the floating-point multiply instruction, and the operation is performed by the floating-point hardware.

    It is well described in Blaauw & Brooks "Computer Architecture Concepts and Evolution",
    and is worse than either yours or my explanation.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From JCampbell@21:1/5 to All on Tue Jul 13 19:42:40 2021
    Thankfully we got IEEE 754 Standard for Floating Point. ( and it's commentary references to bytes such as REAL*8 )

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