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