Release notes for 64 bit FTN95 (beta)

Introduction

FTN95 creates 64 bit executables and DLLs when:

a) the option /64 is used on the FTN95 command line,

b) SLINK64 is used in place of SLINK

c) salflibc64.dll and clearwin64.dll are used in place of salflibc.dll.

FTN95

The initial beta release of FTN95 does not allow you to combine /64 with /debug or /optimise. With this release, developers should use the 32 bit tools and only use /64 for the release version. Also the initial beta release can not handle NAMELIST.

Extended precision (REAL*10) is not available when creating 64 bit applications.

SLINK64

SLINK64 can be used in

a) command line mode

b) interactive mode or

c) script file mode

Here is an example of using command line mode...

         FTN95 prog.f95 /64 
        FTN95 sub.f95 /64 
        SLINK64 prog.obj sub.obj /file:prog.exe 

Here is an example of using interactive mode...

         SLINK64 
        $ lo prog.obj 
        $ lo sub.obj 
        $ file prog.exe 

Here is an example of using a script file...

         SLINK64 @prog.inf 

where prog.inf contains...

         lo prog.obj 
        lo sub.obj 
        file prog.exe 

For further information, on the command line type...

         SLINK64 /help 

Note that the initial release of SLINK64 can create executables and DLLs but not static libraries.

ClearWin+

64 bit ClearWin+ was previously available for use with third party compilers via clearwin64.dll. This DLL has now been extended for use with 64 bit FTN95. Users who have already adapted their code for use with third-party compilers can continue to use their modified code. Alternatively native FTN95/ClearWin+ code can be used without change apart from the following exceptions.

64 bit Microsoft Windows HANDLEs are addresses (64 bit integers). So if a Windows handle is used explicitly in Fortran code, it will currently appear as a 32 (KIND=3) integer and must become a 64 bit (KIND=4) integer for 64 bit applications. FTN95 has a special KIND value (7) that is interpreted as KIND=3 for 32 bit applications and KIND=4 for 64 bit applications. Alternatively INTEGER(KIND=CW_HANDLE) can be used together with standard INCLUDE and MOD files because CW_HANDLE is defined as a parameter with value 7.

64 bit ClearWin+ does not currently support SIMPLEPLOT (%pl). Also a few very old graphics routines have not been ported to 64 bit ClearWin+.

SRC

Use the SRC command line option /r for 64 bit applications requiring resources and link the resulting .res file (together with the .obj files) via SLINK64.

RESOURCES

A RESOURCES directive can be used at the end of a 64 bit Fortran main program but it only has effect when used with /LINK or /LGO. Otherwise a separate call to SRC is required.
(For Win32 main programs, FTN95 automatically adds the resources to the main object file).

Silverfrost INCLUDE and MOD files

Silverfrost INCLUDE files have been modified so that Microsoft HANDLEs have type INTEGER(7).
Silverfrost MOD files can be used without change provided they are updated to those in this release.

Plato

The associated release of Plato is configured by default to use FTN95 when you select "Release x64" on the main toolbar. Previously this used gFortran. The default can be changed from the Options dialog.

Further information

Programs compiled with FTN95 using the /64 switch, use the AMD64 instruction set (subsequently adopted by Intel, and referred to as x64 or x86_64) which is almost universally available on modern PC's. This code cannot be mixed with legacy 32-bit code, nor can it access legacy 32-bit DLL's. 64-bit object files must be linked using the new utility SLINK64. This object file format is incompatible with all other link utilities.

Currently, if the /64 switch is used, /CHECK /OPTIMISE and related FTN95 features are not available. NAMELIST is also not implemented. These restrictions are temporary.

The default size of INTEGER variables remains unchanged (2^31-1), so INTEGER*8 (8-byte) variables must be used to index extremely large arrays. These variables are implemented in a more efficient and natural way in 64 bits. Note that some arrays that would not fit in the old 4GB limit may still be indexable using default sized integers. For example a REAL*8 array of 2,000,000,000 elements would occupy nearly 16GB of memory, but could be indexed using default integers.

The REAL*10 type is not available in 64-bits because of the way the instruction set is organised.

The main value of 64-bit compilation is that the available address space is increased from 4GB to approximately 1.8 x 10^19 bytes! This means that for the foreseeable future (possibly forever!), the size of programs will be limited only by the amount of physical memory available on a system.

Arrays that are ALLOCATEd, or which are in COMMON or in MODULEs, can exceed the 4GB limit, except that initialised arrays must fit within the .EXE or .DLL file to which they belong, and the the size of these files cannot extend beyond the 4GB limit. This is a Microsoft limit, but is fairly reasonable, since the time needed to load a 4GB file would be excessive.

COMMON blocks and MODULE arrays are allocated dynamically as a program starts in order to enjoy no 4GB restrictions. This is applied to all such storage blocks, because a program may exceed the 4GB limit even though each individual array lies within this limit.

Local arrays (static or dynamic) are restricted as in 32 bits. This is because it is not feasible to extend the hardware stack to sizes beyond 4GB, and SAVE'd variables must fit within the EXE or DLL file to which they belong. Users who require a very large local array, should put it in a COMMON block or MODULE referenced by only the one routine.

Since the code can be distributed across multiple DLL's plus an EXE file, the code itself is also not limited to 4GB - although this is not usually a serious concern.

The various 64-bit Windows operating systems provide less than the full 1.8 x 10^19 address space, and the size of this space varies somewhat with the available physical memory on the system. Nevertheless, these limits are very generous and will increase as physical memory becomes more plentiful. In part, these limits are due to the fact that the paging mechanism itself requires memory.

For further information see... https://msdn.microsoft.com/en-us/library/aa366778.aspx

The pair of DLL's SALFLIBC64.DLL and CLEARWIN64.DLL take the place of the 32 bit SALFLIBC.DLL. Currently CLEARWIN64.DLL (which contains much more than ClearWin+) is compiled with Microsoft C++, and requires the file MSCV100.DLL. In the future this may be absorbed into SALFLIBC64.DLL but will remain independent for use with third-party compilers.

Perhaps surprisingly, FTN95.exe and SLINK64.exe are 32-bit executables, and so still require access to SALFLIBC.DLL.

Note that the extra executables and DLL's to support 64-bit mode can coexist with those that support 32-bit operations because they have different names.