Yes it was an extension, but the kind of extension that was “de facto standard” and that could be safely used in practice across compilers. And what was the situation on the C side? Extension as well: the “long long” type has been standardized in C99 (and even worse, only in C++11!).
About using an unsigned type for indexing, it is retrospectively often considered as a design mistake.
64 bits integers have never been a practical issue…
And frankly, who was really needing 64 bits integers for indexes or sizes before 2000 ?
We did a lot of that in 70’s so that we had a practical solution.
As for who was really needing 64 bit integers ?
Anyone who wants to count past 2^31 !
I had a few uses, even if memory was not that big at that time.
I did have a sort routine using integer*8 for sorting ix:iy couples.
@cmaapic
Thanks for the link. It makes me wonder how long the default 32-bit integer will remain with 64 bit Fortran compilers.
I have been seeing problems with this approach from the start and I’m sure these problems will only grow.
Increasingly, I am using 8-byte integers as the kind of choice for new software.
Unfortunately, moving to 64 bit integers (ala old Crays) as default will break a LOT of codes that do either new or old style C interop (netCDF being one). You will now have to either refactor the C code to allow for int64 or refactor your Fortran code to down convert to an int. I agree that moving to default 64 bit ints is something that is increasingly desirable (and needed) but be aware that it will incur a cost.
I think this is the key point. When fortran had only a single type+kind of integer, then it mattered how large that integer was. Also, there are the issues of storage sequence association between that default integer and the default real, logical, and complex types.
But now it is straightforward to declare and use integers of various kinds, and with modules and with TKR argument checking, none of which were available pre-f90, type mismatches can be detected mostly at compile time, so the various kinds are safe for programmers to use. It is not just an issue of having int64 available, in most popular compilers there are also the int8 and int16 kinds available, and programmers can mix and match and chose the best integer kind for the particular need in their code.
Thanks for that link. John Mashey correctly summarizes the situation. Though as usual, he gave short shrift to Cray world (e.g., at CDC and then Cray Research) where 48-, 60-, and then 64-bit integers were the order of the day since the 1960s.
He also mentioned memory mapped files. They have also been around in the virtual memory world since the 1960s. Even with the technology of the 1960s, it was possible to have very large datasets spanning multiple physical disk drives. As he mentions, IBM only supported 24 bits of byte addressing for a long time - which was a problem. It has also always been a real problem with shared libraries gobbling up virtual address space on 32-bit machines too.
One event he didn’t mention was Y2K. In the preparation up to then, standards organizations, compiler developers, operating systems, and applications were compelled to upgrade to handle the problems. Many organizations did a “trash or treasure” with their older equipment and applications. So a lot of old apps that ran in some sort of “compatibility mode” disappeared around then. It will be interesting to see how many old 32-bit-isms remain in time/date processing in 2038.
To index a 3GB 32 bits REAL or INTEGER you need 2^30 values, and a 4 bytes integer can do.
I have not said that 8 bytes integers were useless at these times, but that they were useless for indexing.
Compiler vendors are (and have always been) free to define the default INTEGER as 64 bits. There are good reasons why none of them currently do. But F202Y will normally bring a solution here, by allowing to define the default kind of a type in a programming unit.
Many developers were writing distributed-memory parallel programs in fortran in the late 80s and early 90s, for example with the PVM or TCGMSG libraries, and one feature of this approach was that the aggregate memory could be 10s or 100s of GB. It was convenient to use 8-byte integers to address into this larger space, even if the eventual local array indexes were less than 2GB. This required not only storage of the bits, but also integer arithmetic in that extended precision integer type. As I said previously, in fortran this required a nonstandard syntax for a nonstandard data type for a few years, until f90 compilers became available. When f90 compilers did become available, one realized how much easier the previous decade could have been, and now nice it was to use the fortran KIND system with modules.
I tend to think that such large data at that times were structured data, with 2 dimensions or more, rather than flat data with >2^31 elements, but OK, it could happen.
EDIT: I would object the “many developers”, nonetheless… I checked a Sun SparcStation 10 from the early 90’s, it could accept a maximum of 512MB of RAM, and I guess it was horribly expensive. On the PC side, even the high-end ones, the maximum RAM was considerably smaller. How many of them were needed to manage GBs of data requiring 64 bits indexings, with PVM ?
INTEGER*8 had been around for years and was accepted by all decent compilers for HPC. It was simple and portable despite being non-standard, at a point where some people are still using it today. Of course, it would have been even better to have a standard way, but in practice everybody was satisfied with the INTEGER*8 solution.
The first full CRAY-2 system, ca 1984, had 256 MW (64-bit words) of memory. That is 2 gbytes. A Fortran character string could be almost that long (minus space for OS, etc.) That required 28 bits of word address, plus another 3 bits for byte offset within the word. Fortunately, that era of Cray machine did not support 32-bit data types, so a numeric storage unit (integer/real/logical) was always 64-bits. Main physical memory sizes have gotten ever larger since then.
And again, so have virtual address spaces. Consider the memory mapped file case. Files larger than 2^31 have existed for decades. If you want to address random positions within the file, you need larger address space and larger integers.
Speaking of which, in the early '90s, Cray was developing the T3D system. It had a funny piece of hardware called a “DTB annex” - which allowed using part of the DEC Alpha’s virtual address space to address memory on remote processor/memory environments. Bob Numrich used this to create his F-- library for doing one-sided remote communication. (I was one of his guinea pigs.) One needed 64-bit integers to make this work. A 32-bit integer wouldn’t be able to do it. (CRI used our own compilers for the T3D, rather than DEC’s compilers. So default integers were 64 bits.) This effort eventually turned into the Cray shmem library, and also the one-sided communications introduced in MPI 2.0. Today we also know it as Fortran 2008 co-arrays.
I can remember a few dozen people in my field of quantum chemistry who were developing codes and libraries during this time. Other fields doing parallel computing then included fluid dynamics, monte carlo simulations, and high-energy physics. Worldwide, there were probably a few thousand developers using and developing these kinds of parallel programming tools.
The first machines I used like this in the late 1980s were just workstations connected with ethernet over tcp/ip, so there might have been up to 32 connected and running a single job. But this quickly grew as more sophisticated networking hardware became available on machines with 128 or more nodes.
The NWChem project started about 1990 at PNNL. That was based initially on TCGMSG (which was written by one of my coworkers, R. J. Harrison), and then later replaced with MPI when it became available. This effort also included the Global Array library, designed specifically for the data-distribution of large data sets, which was originally based also on TCGMSG in the early 1990s and later moved over to MPI. The first versions of the GA library were written in fortran. We still have production codes that use the GA library.
OK, but I was specifically answering about the usage of tools like PVM. Not a lot of people had clusters of Cray-2
And to use them from Fortran you needed either an extension or interfacing with C, which was non standard at that time. So having to use another extension (INTEGER*8) was not a big deal in itself.
Both PVM and MPI (prior to V4.0) have the same problem. Count arguments on sends/recvs/etc have a size of “default integer”. Not a problem on Cray machines, where a default integer was 64 bits. This was definitely a problem starting in the 1990s with larger models/clusters, on systems with 32 bit default integers. Annoying to code around it. It took the MPI committee 20+ years to finally resolve things - though perhaps not in the cleanest way they could have.
Brings back dim memories. Vendors with many proprietary options, trying to lock everyone in to their OS, 60-bit and other unusual word sizes, segldr, NOS, NOS/VE, SCOPE, COS, VMS, HP-UX, Aegis, Primes, CAL, COMPASS, AIX, True64, … all with different Fortran versions and hardware limits.
Luckily we had a collection of Fortran codes that checked for standard usage and a strict policy that if you needed anything that was non-standard you asked the central corporate group to provide the feature with a standard library; as we had codes that had to run on many different OSes. So all the OS-specific features (even getting the date and time until f90, which seems unimaginable) were internally standardized. Amazingly it worked very well, and although the company is gone and previous divisions were bought and sold multiple times some of the codes are still in use many decades later. Instead of memory management being supported via custom async I/O to multiple tapes the routines now are just wrappers to standard allocatable arrays, and so on but self-describing portable binary files, graphics and steam property libraries, OS (later POSIX-conforming) libraries for file management, … were all provided by the central group as black-box implementations; so we avoided a lot of the old issues described here, but not without a non-trivial cost to provide it. I sometimes forget just how chaotic it was. I remember hating having to know a dozen editors just to be able to edit text files. Somewhere I have the code for a look-alike of the CDC (NOT IBM) NOS xedit editor (a line editor; screen-based editors were rare and highly non-portable) we used to put up on every system with C so there was a common editor available on all systems so you could at least change a config file with the same commands no matter what OS you were on, and on and on and on …
But looking back having a standard library and strict requirements to make code portable, plus access to dozens of versions of Fortran so you could actually test your code was portable saved us a LOT of grief.
I knew someone in the late 1970s who wrote a line editor in fortran. When he ported his codes to a new machine, that was the first program he would convert, and he would then bootstrap the rest of his application codes (quantum chemistry) using that editor.
I took a different approach. I learned to use emacs, which was available on almost every machine, and I used that as my least common denominator. Even on a VAX, which had an excellent screen editor (EDT, I think it was called) at that time, I still used emacs just to keep in practice with it. I remember by the mid 1980s there were even two or three versions of emacs that I could choose on the VAX. One of them (I forget the name now), had an option to minimize terminal i/o, so you could even use it over a 300 baud dial-up.
