[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.

Did Fujitsu copy the precision reducdtion feature from IBM?

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.

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.

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.

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