Problem with Do loops

[WSinc]

This problem occurs when the DO INDEX 8 bytes.

I admit that we should not see this very often, but

apparently the lower and upper limits cant be more than 32 bits.

for example this Do Loop does not execute properly:

Integer (8)  ix

do    ix=1,2**36

enddo

It does not do ONE pass thru the loop, as if the upper limit is negative.

If the upper limit is 31 bits (the largest possible 4 byte number) then it executes properly.

Is this documented anywhere ?

[FortranFan]

jimdempseyatthecove wrote:

.. These programs were written in FORTRAN IV for the PDP-8 series of computers. ..

Interesting.  Would the following link be a representative system documentation of the computers you were using?

http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp8/os8/AA-H609A-TA_OS8_Language_Reference_Manual_Mar79.pdf

The reason I ask is because the FORTRAN IV language reference clearly shows the range of valid values for INTEGER constants (-2**23 to 2**23 - 1) and it also only indicates declaration statements as 'INTEGER ..'.  The documentation doesn't suggest INTEGER*n or INTEGER(n) as being allowed, perhaps that came later/earlier on other computers?  From what I can see, none of the standards including ANSI FORTRAN 66 and 77 ever recognized INTEGER*n whereas INTEGER(n) has been allowed starting with IEC ISO Fortran 90.

Nonetheless any valid functioning program on this PDP-8 system using FORTRAN IV - at least from the perspective of INTEGER constants, variables, and DO loops with control indices of INTEGER type - will likely work the same with a Fortran 2018 compiler on a modern computer which is good.  And vice versa too with restrictions i.e., if one writes standard-conforming code toward a modern computer with a Fortran 2018 compiler, it can be backported to work on a PDP-8 system running FORTRAN IV provided the code is constrained to declaration of default basic types (thus no defined kinds as in INTEGER(n)!), the ranges of these types are limited to those by PDP-8 such as 2**23 - 1, uses fixed-form source with upper case, etc.  But of course, the issues will arise when 64-bit and other computing tasks are to be attempted as with OP who wants to extend the INTEGER range to 2**36 and beyond.

[FortranFan]

.. the support of literal constants in the current Fortran standard is not without issues.  Coders also take on risk of unexpected results when they fail to append (or prepend) the KIND to the constant...

Fortran standard says

The keyword INTEGER with no kind-selector specifies type integer with default kind; the
kind type parameter value is equal to KIND (0). The decimal exponent range of default
integer shall be at least 5

and

The optional kind type parameter following digit-string specifies the kind type parameter of
the integer constant; if it does not appear, the constant is default integer

So note the Fortran only requires the default integer to have values within the range of -10**5 and 10**5.  Of course an implementation can provide an extended range for default integer, as Intel Fortran does on the 3 main platforms it supports.  But that may not always hold on other computers and/or other compilers.

Thus any code where the integer constant has a value outside the range of -10**5 to 10**5 as in say

integer :: i, n
..
n = 10**5 + 1
..
do i = 1, n

faces the risk of the issue in the original post.

Hence the suggestion to use defined kinds and named constants that confine literal constants in assignments or constant expressions to allow for secure and portable code in Fortran, 

[gib]

Since we're talking about old hardware, here's my 2c worth.  My first PC was a Zenith Z100 (all-in-one computer, screen, keyboard, dual floppy drives, S100 bus).  The interesting thing about this machine was that it had an 8-bit CPU (8085) and 16-bit (8088), and could could boot either CP/M (8-bit) or Z-DOS (16-bit).  Z-DOS was almost the same as MS-DOS (which came out about the same time), but different enough to create some incompatibilities.  I think Z-DOS came from the same place as MS-DOS, i.e. Seattle Computer Products (Tim Patterson).  Another interesting thing: along with the machine one received in big ring binders the complete BIOS code for both OSes.  I did manage to acquire a Fortran compiler, I'm not sure but I think it was FORTRAN IV.  I think this may have been the first machine that AutoCAD ran on.

[jimdempseyatthecove]

>>The reason I ask is because the FORTRAN IV language reference clearly shows the range of valid values for INTEGER constants (-2**23 to 2**23 - 1) and

You are right.... it's been over 50 years :).

Prior to the OS/8 FORTRAN IV, I did use Fortran II on the 4K word PDP 8/L in the physics lab. The compiler was merge compiled with the application in three passes on a 10cps paper tape reader. This produced SABR assembly source code, which then had to be assembled with the SABR assembler (10cps paper tape), only then could you load the final binary paper tape in for testing (and repeat if bug found). One tended to perform rigorous visual code walkthroughs on their notepads (yellow paper tablets, legal format), or printouts if they had one. One went through all the single letter variable names first, two letter second, ... and left the comments off for later hand writing on the printouts.

The college later (following year) installed a PDP8-I with 24K words, two 250K word, word addressable, disks (RF08), three DEC-Tape tape drives, high speed paper tape (120cps), line printer, card reader, card sorter,  running a timeshare operating system that presented each user (12) a 4K word virtual machine. The system would also run standalone OS/8 for administrative work. The users, used 10cps TeleType terminals (keyboard, paper role printout, tape reader/punch). Later on they upgraded to 32K word, four 250K word disks, 3 tape drives, two removable 1.6M word/ 2.5MB hard drives (RK05) 14" platter. This was a world of difference.

The first highly productive program I wrote for this system was the college had their administrative department starting to occupy more of the available time on the system than for educational purposes. Their log-jamb was a multi-reel tape to tape sort. This took 8 hours or longer depending on the number of tapes. This was running stand-alone. I wrote my sort program to run in the virtual 4K word user virtual machine, used part of the 250K-500K word hard drive for temporary work space and got the tapes streaming in on the input side, while sorting, and streaming out on the output side. What took 8 hours or so now could be done in a hand full of minutes.

Jim Dempsey