The Silverfrost Fortran compiler FTN95 creates 64 bit executables and DLLs when:
Silverfrost Fortran tries to make code work in both 32 and 64 bit modes. For most applications and systems you won't notice the difference. There are some differences though:
64 bit FTN95 is a progression from Win32 FTN95 and not .NET FTN95. So the command line option /64 cannot be combined with /CLR.
The Silverfrost 64 bit linker SLINK64 can be used in:
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 see below or type...
SLINK64 /help
SLINK64 automatically scans commonly used Windows DLLs. If a Windows function located in (say) xxx.dll is reported as missing then the DLL should be loaded by using a script command of the form
lo C:\Windows\Sysnative\xxx.dll
where C:\Windows illustrates the value of the %windir% environment variable.
Note that SLINK64 can construct executables and DLLs but not static libraries. Users can create a static library by constructing a master file containing only INCLUDE statements for the relevant files. Compiling the master file will create a .obj file that is equivalent to a static library file.
The 64 bit debugger SDBG64 operates in essentially the same way as the corresponding 32 bit debugger SDBG.
64 bit ClearWin+ was available (before 64 bit FTN95) for use with third party compilers via clearwin64.dll. This DLL has been extended for use with 64 bit FTN95. Users who have 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 HANDLEs are addresses (64 bit integers). So if a Microsoft handle is used explicitly in 32 bit Fortran code, it will 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. Microsoft HANDLEs are mainly used with %lc (Handle of Last Control), %hw (Handle) and some direct calls to the Windows API. For further information see Using Microsoft handles.
The winio@ edit control %eb (Edit Box), when used with a grave accent, requires a user-supplied "edit_info" array or TYPE. For 64 bit programs, some of the items in the array become 64 bit addresses so for 64 bit applications users are advised to avoid the array form and use only TYPE(edit_info) which is defined in the standard INCLUDE files (such as clearwin.ins) and the associated modules. For example:.
INCLUDE <clearwin.ins>
INTEGER i
INTEGER(2)::handle,err_code
TYPE(edit_info) info
i=winio@('%60.20`eb','*',0,info)
IF(info%modified > 0)THEN
i=winio@('%cnSave changes?%2nl%6bt[Yes] %6bt[No]')
IF(i.EQ.1)THEN
CALL openw@('myfile.txt',handle,err_code)
CALL writef@(CCORE1(info%buffer),handle,info%buffer_size,err_code)
ENDIF
ENDIF
END
The function CLEARWIN_INFO@ now returns an INTEGER(KIND=7) value.
A few very old (DBOS) graphics routines have not been ported to 64 bit ClearWin+. Other DBOS routines are available (e.g. DRAW_TEXT@) but now require an explicit interface that can be found in the INCLUDE file called dbos.ins.
The function CPU_CLOCK@ is not available for 64 bit applications and has been replaced by rdtsc_val@...
INTEGER(KIND=4) FUNCTION RDTSC_VAL@()
The following undocumented Win32 routines have been ported to 64 bits:
FPOSLONG@, RFPOSLONG@ and FPOS_EOFLONG@.
These are similar to FPOS@, RFPOS@ and FPOS_EOF@ but take INTEGER*8 position arguments. Note that other arguments are INTEGER*2.
SRC is the Silverfrost Resource Compiler. Use the SRC command line option /r for 64 bit applications and link the resulting .res file (together with the .obj files) via SLINK64. Current experience suggests that using the "default.manifest" in a resource script causes the resulting 64 bit application to fail to load. However, a user-supplied manifest file can improve the appearance. The text of a suitable manifest file is presented below.
An FTN95 RESOURCES directive can be used at the end of a 64 bit FTN95 main program
but it only has effect when used with FTN95 command line options /LINK or /LGO.
Otherwise a separate call to SRC is required.
Silverfrost INCLUDE files have been modified so that Microsoft HANDLEs have type INTEGER(KIND=7). Silverfrost MOD files can be used without change provided they are updated to those in a release of of 64 bit FTN95.
Note that user FTN95 MOD files for 64 bit applications may differ from those for 32 bit applications. So FTN95 uses the extension .mod64 for 64 bit MOD files whilst retaining the extension .mod for 32 bit MOD files. The corresponding object files always differ and the respective linker (SLINK or SLINK64) will reject object files of the wrong kind.
By default FTN95 uses the extension .obj for both 64 bit and 32 bit object files. For projects, both Plato and Visual Studio retain the default extension and use a system of sub-folders in order to create executables for different platforms (such as Win32, x64 and .NET) and for differenct configurations (such as Debug, CheckMate and Release).
Users who prefer to build their applications using batch and/or makefiles can adopt a similar sub-folder approach to that used by Plato and Visual Studio. Alternatively, 64 bit object files can be given a different extension (e.g. .o64) by using /BINARY (together with the object file name) on the FTN95 command line. In that way, 64 bit and 32 bit object files could reside in the same folder.
An associated release of Plato (the Silverfrost integrated development environment) is configured by default to use FTN95 when you select "Release x64" etc. on the main toolbar. Previously this used gFortran. The default can be changed from the Settings dialog.
Plato can launch the 64 bit debugger SDBG64 as an internal process or as an external application.
Like salflibc.dll, salflibc64.dll and clearwin64.dll can be freely redistributed with your applications and DLLs.
1) The Fortran Standard stipulates that the SIZE intrinsic function (without a KIND argument) should return an value of default integer type. For FTN95 this is a 32 bit integer unless the default is changed via a command line switch. FTN95 is not standard conforming in this respect unless /SIZE_ISO or /ISO is used on the command line. In other words, SIZE usually provides a 64 bit value. An exception to this rule is that a call to a routine of the the form FUNC(SIZE(...)) is standard conforming. This is because the type of an argument will be critical when used with generic functions. LBOUND and UBOUND are similar but are always standard conforming (by default they return a 32 bit integer).
2) It is possible that there may be some slight loss of precision when porting from 32 bit to 64 bit calculations. This is mainly because some FTN95 32 bit mode floating point calculations actually use hidden extended precision on the way to producing double or single precision results. It is therefore possible that the process of porting to 64 bits may expose a numerically unstable calculation (i.e. one that depends critically on the level of round-off error). In the same way, in extreme cases it is possible that new exceptions may appear at runtime due to floating point overflow. Overflow can occur directly or as the result of dividing by a value that has underflowed to zero. In some cases it is possible to resolve these issues by using a scaling factor in the calculations.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly> <assemblyIdentity type="Win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0"
processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*"/>
</dependentAssembly>
</dependency>
</assembly>