[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?
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.
On Tuesday, August 23, 2022 at 1:36:09 PM UTC-7, Thomas Koenig wrote:
(snip)
The compiler closely followed IBM Fortran compilers (littleI didn't know this before, but VS Fortran, the IBM Fortran 77 compiler,
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.
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 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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 159 |
Nodes: | 16 (0 / 16) |
Uptime: | 98:51:17 |
Calls: | 3,209 |
Files: | 10,563 |
Messages: | 3,009,783 |