• Re: Option to cut off digits in old Fortran compiler

    From gah4@21:1/5 to Thomas Koenig on Tue Aug 23 14:39:28 2022
    On Tuesday, August 23, 2022 at 1:36:09 PM UTC-7, Thomas Koenig wrote:
    [x-post, f'up]

    When I worked on a Siemens/Fujitsu mainframe running BS3000, an MVS
    clone, the Fortran 77 compiler had a switch to reduce the accuracy
    of floating point calculations in order to find numerical problems.

    The compiler closely followed IBM Fortran compilers (little
    surprise there), even in debatable things like the AT statement,
    a variant of COME FROM, but only for debugging. I wonder how
    many programs only worked with this enabled... but I digress.

    The debug feature and debug packets came from Fortran G.
    I didn't remember that they went into VS Fortran, which is the IBM
    Fortran 77 compiler for such systems.

    Did Fujitsu copy the precision reducdtion feature from IBM?

    I don't know of any precision reduction feature for HFP, BFP, or DFP
    on S/360 descendants. It would not be hard to store them in
    memory and then NC (that is, AND) off the low bits. Or it is possibly
    a Fujitsu hardware extension.

    Reminds me though of a feature of the IBM 7030 that, as far as I
    know, never made it into any other processor. The 7030 has a
    console switch that sets the bits shifted in on post-normalization,
    to either 0's or 1's. The idea is that you would run the program both
    ways, and differences were caused by loss of precision in subtraction.

    That would seem more obvious for finding numerical problems, though
    not so easy to do along with the hardware floating point.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From gah4@21:1/5 to Thomas Koenig on Tue Aug 23 18:18:52 2022
    On Tuesday, August 23, 2022 at 1:36:09 PM UTC-7, Thomas Koenig wrote:

    (snip)

    The compiler closely followed IBM Fortran compilers (little
    surprise there), even in debatable things like the AT statement,
    a variant of COME FROM, but only for debugging. I wonder how
    many programs only worked with this enabled... but I digress.

    I didn't know this before, but VS Fortran, the IBM Fortran 77 compiler,
    and successor to Fortran G and H, does have the DEBUG feature
    from Fortran G.

    I don't know at all the connection between IBM and Fujitsu compilers.
    Maybe they just license the IBM compilers.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From jfh@21:1/5 to All on Wed Aug 24 01:56:15 2022
    On Wednesday, August 24, 2022 at 1:18:55 PM UTC+12, gah4 wrote:
    On Tuesday, August 23, 2022 at 1:36:09 PM UTC-7, Thomas Koenig wrote:
    (snip)
    The compiler closely followed IBM Fortran compilers (little
    surprise there), even in debatable things like the AT statement,
    a variant of COME FROM, but only for debugging. I wonder how
    many programs only worked with this enabled... but I digress.
    I didn't know this before, but VS Fortran, the IBM Fortran 77 compiler,
    and successor to Fortran G and H, does have the DEBUG feature
    from Fortran G.

    I don't know at all the connection between IBM and Fujitsu compilers.
    Maybe they just license the IBM compilers.

    Decades ago I was visiting Cambridge University UK and used their IBM mainframe. It had IBM and Fujitsu Fortran compilers, which must have been different because the advice we were given was that the Fujitsu compiler was better.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Gary Klimowicz@21:1/5 to gah4@u.washington.edu on Wed Aug 24 14:59:32 2022
    gah4 <gah4@u.washington.edu> writes:

    On Tuesday, August 23, 2022 at 1:36:09 PM UTC-7, Thomas Koenig wrote:
    ...
    Did Fujitsu copy the precision reducdtion feature from IBM?

    I don't know of any precision reduction feature for HFP, BFP, or DFP
    on S/360 descendants. It would not be hard to store them in
    memory and then NC (that is, AND) off the low bits. Or it is possibly
    a Fujitsu hardware extension.

    Reminds me though of a feature of the IBM 7030 that, as far as I
    know, never made it into any other processor. The 7030 has a
    console switch that sets the bits shifted in on post-normalization,
    to either 0's or 1's. The idea is that you would run the program both
    ways, and differences were caused by loss of precision in subtraction.

    That would seem more obvious for finding numerical problems, though
    not so easy to do along with the hardware floating point.

    When I was at New Mexico Tech, we had an IBM 360 Model 44.
    It was "designed" for scientific computing, so it didn't have
    the commercial instructions (move characters, and the decimal
    instructions).

    It had a dial on the front panel to select the binary mantissa
    precision for 64-bit floating point. You could limit it to 32-56
    bits (in 8-bit increments). This sped up floating-point
    instruction execution, of course.

    I was only there for a year, but I wasn't aware of anyone
    requesting an unusual value for it (32, 40, 48) for their jobs.

    There's a nice little Wikipedia article here: https://en.wikipedia.org/wiki/IBM_System/360_Model_44

    --
    gak

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