FTN95 64-bit beta test

Dan,

I agree, as FTN95 has probably the best error checking of any compiler I have used.

The new /64 features, especially the ability to have individual common blocks larger than 2gb, should be seen as a significant new feature. All other 64_bit compilers I have tested do not support this feature.

What it means is that existing F95 code can be easily expanded to 64-bit by providing larger arrays, without the need for major code changes that adopting ALLOCATE can require. This is the case while existing arrays can utilise I4 subscripts, which will be typical in the short term for most existing physical memory configurations. ( 16gb for real8 arrays )

I think the ease of converting is a big selling point for using FTN95 /64 with existing F77 and F95 code.

Based on my experience, this can be a very easy path to solving larger problems in a larger memory space for little effort. I did this with my clearwin+ based graphics program, which I converted to use 2.9 gb of memory with the change of a few parameter declarations. I compiled and linked 230 .f95 files using /64 in one night, with the only significant changes being 1) identifying and changing window handles to I*8 and 2) updating the @link.txt file for SLINK64. The get_filtered_file@ problem is now gone! This is a program that I had not spent a lot of time restructuring for 64 bit, which other compilers require converting to ALLOCATE array structures.

For those who are memory constrained with clearwin+ programs, this will be a very welcome improvement.

Paul's suggestion of using /32 with a smaller data-set for debugging can be a good approach, although I think a lot of Dan's problems with clearwin+_32 do relate to memory squeeze associated with virtual graphics regions. These disappear with /64, ie the /32 and /64 programs will not perform the same, so these types of errors will not perform the same with and without /debug.

Based on my Beta testing, I recommend /64 as worth adopting when available.

John

I love this company ! Not MS of course https://www.youtube.com/watch?v=f__n8084YAE

Just make me /64 and with the 64bit debugger ASAP, I need to load 100GB of data any PIC code nowadays generates. (By the way, I am much less interested with 64bit Clearwin, John)

OpenMP and MPI compatibility and multithreading debugging and

/optimize to be in par with other compilers. i do not need to beat them, major and most cost consuming is still the DEVELOPMENT SPEED, depth of error checking and features where this compiler is a Godzilla, not the run speed. But the speed improvement will be welcome

Quoted from PaulLaidler

A new 'backend' has been to added to FTN95.exe for 'x64' to go alongside the existing backends for 'Win32' and '.NET'. These backends generate the relevant assembly instructions for each platform.

The 64 bit version works also for .NET or it is only a 'Win64'?

Quoted from Emanuele

The 64 bit version works also for .NET or it is only a 'Win64'?

As I understand it:

There are three target classes: win32, win64 and .NET. For each there is a dedicated back end. All target classes share the same front end. Presumably, the front end produces some kind of intermediate language which is the same for all targets. The back ends reads this intermediate language code and output the corresponding x86, x64 and CLR objects.

Thus, the question regarding 64-bit for .NET may not be meaningful. There are other external issues: does the CLR virtual machine/interpreter translate .NET code to x86 instructions or x64 instructions? Are all support DLLS available?

The current 64 bit development program does not include .NET. In theory it might but in reality it doesn't.

As long as SDBG and /CHECKMATE are still supported in 32 bit mode then it will be possible to debug codes. Often small test data sets are sufficient to complete all debugging.

Quoted from mecej4

does the CLR virtual machine/interpreter translate .NET code to x86 instructions or x64 instructions? Are all support DLLS available?

It seems to me that the answer is x86 and the linker refers to the 32 bit version of .NET dlls. In this sense the question of x64 .NET may be meaningful.

Quoted from PaulLaidler The current 64 bit development program does not include .NET.

I can understand that in this first phase of the development the .NET 64 is not the priority, however I hope that it will be included in the program soon after the release of win64.

Emanuele

I am sorry to disappoint you but there are currently no plans to extend .NET to x64.

Hello,

I am trying to build a 64 bit library from file hello_fort1.for using option /mklib. File hello_fort1.for consists of the following code

subroutine myprint(C10)
      
      CHARACTER*1 C10
      
      write(2,'(A)') C10
      return
      end

and I tried to create the library by executing command ftn95 hello_fort1.for /64 /mklib . However, this resulted in an access violation producing the following text

Access Violation
The instruction at address 10011b53 attempted to read from location 00000000

 10011b37 strcat [+001c]
 00516d04 nt_link(void) [+077f]
 005165a2 finish(void) [+0507]
 00401000 main [+0598]

eax=00589e00   ebx=00000000   ecx=ffffffde
edx=0008e3c8   esi=00000000   edi=00589e78
ebp=03d9d544   esp=03d9d528   IOPL=0
ds=002b   es=002b   fs=0053
gs=002b   cs=0023   ss=002b
flgs=00210206 [NC EP NZ SN DN NV]

 10011b53  lodsb
 10011b54  stosb
 10011b55  cmpb     al,0x0

. No library is generated, however, file hello_fort1.obj is created. Executing command hello_fort1.for /mklib works as expected and produces file hello_fort1.lib and not file hello_fort1.obj. I am using the new beta-2 release (Version: 8.00 beta.14 Built: Thu Oct 8 17:44:44 2015).

Comments are welcome. Regards, Dietmar

Hello again,

sorry, there was an incorrectness in my previous post. The second command mentioned in the post was meant to produce a 32 bit library using option /mklib and this worked. The command should read ftn95 hello_fort1.for /mklib , I forgot the ftn95 command name in the post.

Regards, Dietmar

Dietmar

At the moment, FTN95 should not accept /MKLIB with /64 and I have now fixed FTN95 so that it gives an error report for this combination.

/MKLIB causes FTN95 to spawn to SLIM (the 32 bit static library manager) and SLIM has not yet been extended to 64 bit object files.

Also, at the moment, SLINK64 can not create static libraries.

Let me know if the use of static libraries is import for you. In theory one should be able to simply concatentate .obj files together in order to produce a .lib file and there is a DOS command to do this.

Paul,

For 32 bit, I make extensive use of static libraries, made using slink. I use basic commands, example below. It would be good if this functionality was also available with slink64, at some stage. (I have never found a compelling need to change to a .dll approach.)

archive crtlib.lib addobj border.obj ... addobj quitest.obj file

Based on your post above, is the DOS equivalent simply 'copy *.obj crtlib.lib' then use 'le crtlib.lib' in slink64 ?

John

John

Further work on SLINK64 and/or SLIM is planned in order to accommodate 64 bit static libraries but I was looking for a quick short term fix.

I was hoping that a DOS command like COPY would do the trick but I have tried COPY and it does not work for me. The alignment of the runtime machine instructions goes wrong. It might be quicker to fix SLINK64 or SLIM so I will see if we can move this up the priority order. I will also try to recover what we used to do before SLINK/SLIM was finished.

Hello,

I am also using static libraries very extensively. For porting short applications and for the time being, I link 64 bit object files directly. I would appreciate very much if you would support some functionality to build and link against 64 static libraries.

In this context I wonder if I can create 64 bit objects, libraries or executables from C/C++ code using scc.exe. We make use of 64 bit object files built from C source code, as well.

Regards, Dietmar

Hello,

I am trying to port a Fortran 32 bit application to 64 bit which makes use of substrings. The position indices used are of type INTEGER*2.

Both the 32 bit and the 64 bit application may be successfully created using the beta 2 version of ftn95 (Version: 8.00 beta.14). However, while the 32 bit executable works as expected, the 64 bit executable produces an access violation.

Here is the source code referred to as sample1.for for the following.

      IMPLICIT NONE
      
      INTEGER*2 LPTTCMD
      PARAMETER(LPTTCMD=256)
      CHARACTER MYCMDLINE*(LPTTCMD)

#if BAD
      INTEGER*2 ITA, ITE
      ITA=1_2
      ITE=2_2
      write(*,*) 'INTEGER*2 case'
#else
      INTEGER*4 ITA, ITE
      ITA=1_4
      ITE=2_4
      write(*,*) 'INTEGER*4 case'
#endif
            
      CALL COMMAND_LINE(MYCMDLINE)
      write(*,*) 'ITA=',ITA
      write(*,*) 'ITE=',ITE
      write(*,*) 'MYCMDLINE(ITA:ITE)=',MYCMDLINE(ITA:ITE)
      if (MYCMDLINE(ITA:ITE) .eq. '/?') then
        !+ Help-Text ausgeben
        stop
      else
        write(*,*) 'Didi1 ', 'ITA=',ITA

        if (MYCMDLINE(ITA:ITA) .eq. '-') then
          write(*,*) 'Fehler: Unbekannte Option' // MYCMDLINE(ITA:ITE)
        else
          write(*,*) 'Didi2'
        endif
      endif
      
      stop
      end

The 64 bit exexcutable is created via comands ftn95 sample1 /ALL_WARNINGS/NON_STANDARD/SINGLE_THREADED/OLD_ARRAYS/ALT_KINDS/PERSIST/ZEROISE/UNLIMITED_ERRORS/FIXED_FORMAT/SAVE/NO_WARN73/WIDE_SOURCE /CFPP /BINARY_folder SALFORD64 /64 /DEFINE BAD 1

and

slink64 SALFORD64\sample1.obj /file:SALFORD64\sample1.exe

. The definition of C preprocessor flag BAD forces the type of variables ITA and ITE to be INTEGER*2 . The call

SALFORD64\sample1.exe dd

forces the access violation. The last string displayed is 'Didi1 ITA= 1'. Now by not defining preprocessor flag BAD, e.g. by executing command

ftn95 sample1 /ALL_WARNINGS/NON_STANDARD/SINGLE_THREADED/OLD_ARRAYS/ALT_KINDS/PERSIST/ZEROISE/UNLIMITED_ERRORS/FIXED_FORMAT/SAVE/NO_WARN73/WIDE_SOURCE /CFPP /BINARY_folder SALFORD64 /64

and linking as mentione above, the type of ITA and ITE is changed to integer*4. Thus the application created works as expected which may be seen from the string 'Didi2' which is displayed after the string starting with 'Didi1'.

As the corresponding 32 bit application runs successfully in both the integer2 and the integer4 case I wonder what has gone wrong in the error case.

Regards, Dietmar

Dietmar,

To link with slink64 I use the command: slink64 @saplot_load.txt >> ftn95.tce

I have created 'saplot_load.txt' by importing the 32 bit saplot.map into Excel and using a pivot table to generate a list of .obj files that were extracted from my .lib files. eg: adapting c:\clearwin\clearlib.dev\crtlib.lib (crtcrd.obj/ )

It all worked first try! although it would be more difficult to generate a greenfield link list.

I was also surprised by the compile options you have used with /64. It would be good to have a list of valid (or unsupported) compile options that work with /64. I notice you use /ALT_KINDS. Do you find any problems with this option ? as I am contemplating this as my default. I try to avoid use of /OLD_ARRAYS /ZEROISE or /SAVE as they have significant portability problems.

My experience to date with /64 has been very good. For my %gr graphics program, I have been able to expand the data I retain in memory, using a few ALLOCATE arrays and speed up both run time and development of new (enhanced) analysis options.

John

Dietmar

We are developing SCC /64 alongside FTN95 /64. SCC /64 is used to build salflibc64.dll. SCC /64 will be fully developed and tested in due course but is not yet ready for beta release. In the meantime it is possible to use FTN95 /64 with a third party C/C++ compiler particularly (and perhaps only) if the C/C++ part is formed into a standard 64 bit DLL.

I have made a note of the FTN95 /64 coding problem that you have posted and I will get back to you as soon as possible on this issue.

John

Your approach to linking is novel but I wonder if you are mostly just unpacking and then repacking. For an alternative approach, you can have as many subprograms as you like in one file, compile a .obj file from it and then treat the resulting .obj file as a library. Or you can use INCLUDE statements to create a master file from many separate files, compile the master file and treat the master.obj as a library. The only limitation is that (at the moment) SLINK64 will complain if you call the file master.lib rather than master.obj. Also, for the moment, very large files are slow to compile but this is something we are working on and will soon be resolved.

Paul,

I didn't think my approach was too novel. I was simply replacing the selective library loads 'le \tree\bin.lib' with the list of 'lo \tree\file.obj', hopefully until I can generate a /64 bin.lib. You are correct that I could generate a bin.obj file if bin.f90 included all required tree\*.f90 files.

I was trying to emulate the selective load of .obj files from bin.lib, which also contains other .obj files.

I have found that using slink64 @saplot_load.txt is a simple approach, which I use for other compiler/linkers that I have not bothered to learn their slim equivalent.

My laziness extends to not using .dll's as I have not yet found a compelling reason to change. A static load has the benefit of not loosing the .dll when copying the .exe to another pc.

Is there any update on the cou@ problem, or should I scrap it's use.

John

Dietmar

The INTEGER*2 problem has now been fixed.

John

The COU@ problem has now been fixed.

John,

the options I used in my latest post come from our 32 bit build environment (except of /64) and worked. So in a first porting approach to 64 bit I did not change any of these options.

For 32 bit compilations I have not found any problems with option /ALT_KINDS

Paul,

good news (concerning the scc and the integer*2 problem). I am looking forward to a first version of scc for 64 bit.

Regards, Dietmar