Converting 32 bit to 64 bit

A requirement to up our 32 bit software to 64 bit means all the FTN95 extensions that have been used need to be removed or replaced. This is a major upheaval and will be a costly exercise.

I would be grateful if you could provide suitable F90 equivalent replacements for the following intrinsics : CORE4, LOC, LENG, RS, LS ( others may rear their heads in due course ! ). I presume this equivalents will be acceptable to gFortran and NAGfor ?

On another matter : will calls we make to routines via STDCALL to our Delphi created DLLs be unaffected by the 'move' from FTN95 ?

Thanks

LENG, RS and LS can be converted to standard conforming intrinsics.

CORE4 and LOC will need special attention and the alternative will depend on how they are used.

You will not be able to access 32 bit (Dephi created) DLLs. These will need porting to 64 bit DLLs.

Our current commitment is to provide a means of porting code that is Fortran 95 standard conforming and that uses the ClearWin+ library. This means that user's will need to adapt their code if it uses FTN95 intrinsics that are extensions to the standard.

LENG(str) is the same as LEN_TRIM(str).

RS(i, k) is the same as ISHFT(i,-k)

LS(i,k) is the same as ISHFT(i,k)

CORE4(0) is usually used as an argument to pass a NULL pointer. gFortran will need a pointer of the correct type. If you can give me the context, then I may be able to help.

LOC(x) provides the address of x and your code may need to be rewritten at this point.

Thanks for confirming the f90 equivalent functions. Below are various examples of other extended FTN95 intrinsics.

[u:4c7b7757b5]Example of the LOC and CCORE1 usage[/u:4c7b7757b5]

Where screen dialog variables are passed to a routine to build an integer field we store the address of this variable so that it can be automatically updated. Thus, the calling routine has knowledge of the latest value set by the routines behind the screen dialog. So,

  IADDR(N12,INDTYP) = LOC(CODE)

where CODE is the variable passed into the routine. IADDR will be used to update the variable,

  CALL MOVE@(CCORE1(IADDR(IND,INDTYP)), CODEIN, 4)

where CODEIN is just a local variable within the 'building block' routine. Once updated, by the user using a 'browse' or 'select' button associated with the screen dialog input field then the calling routine's variable needs to be updated,

     CALL MOVE@(CODEIN, CCORE1(IADDR(IND,INDTYP)), 4)

[u:4c7b7757b5]Other CORE examples[/u:4c7b7757b5]

We also use CORE2,

  CALL MOVE@(CORE2(ILP), ILPRM(1), 48)

and CORE4

        DO I = 0, INFOEB(15)-1
           CORE4(INFOEB(17)+I*4) = IPAL(NDPCOL(NCOL))
        ENDDO

Thanks

Paul, I presume that XOR and AND are equivalent to the f90 IEOR and IAND intrinsics ?

Thanks once more

There is a LOC function in gFortran. I can not see anything like fcore4 etc. but here is one way to resolve the issue.

In a Plato project a C file contains...

extern 'C' float fcore4(long long pVal)
{
  float* p = (float*)pVal;
  return *p;
} 

In the same project a Fortran file contains...

      program main
      real x
      interface
       function fcore4(v) bind(C,Name='fcore4')
        use ISO_C_BINDING
        real(C_FLOAT)::fcore4
        integer(C_LONG_LONG),value::v
       end function fcore4
      end interface
      integer*8 addr
      x = 42.0
      addr = loc(x)
      print*, fcore4(addr)
      end

And this gives the expected result. I could add these functions to the new DLL.

I have just noticed your second post.

With all of these intrinsics it is just a case of running a few tests to see how the old and the new intrinsics perform.

You mentioned a Delphi DLL. Will you be able to port this to 64 bits?

Thanks Paul.

I have proved creating specific LENG, RS and LS functions performs satisfactorily in FTN95. The use of IEOR and IAND do indeed seem fine.

I look forward to proving the LOC facility in gFortran.

I presume by updating the DLL based on the requirements of the FTN95 'core' intrinsics you mean that we shall just need to access the new Clearwin64 entries named CCORE1$, for example ? If you are able to acheive this we would be most grateful.

We shall need to investigate the availability of 64 bit Delphi and what that may mean as far as differences between the two environments with regard to string lengths/definitions.

I compiled one of our source FTN95 files replacing all occurrences of @ by \(. I also replaced the 'INCLUDE <windows.ins>' by inserting 'USE mswin\)' at the top of the fortran before the first IMPLICIT. After copying the $ modules into the FTN95/include folder I ran a FTN95 compilation. Sadly, I got an Access Violation referring to 'check_argument_list' problems. Any ideas, please ?

I don't have any immediate thoughts on this.

I would recommend that you follow the instructions in files ClearWin64.txt and readme.txt that are described in the download information.

If you can get the test suite to run then you can be confident that you have everything set up correctly.

When compiling a test suite example an error is issued stating 'clearwin64f.a' and 'clearwin64.a' do not exist within the FTN95 folder.

Are these files installed only with the latest v6.3.1 ?

Yes. These files are in the current beta download together with FTN95 version 6.3.1.

The self-extracting archive for the beta download uses a default extraction path. This path corresponds to the standard default path for Silverfrost FTN95 and for 64 bit operating systems but may not be the right one for your machine.

I have uploaded a new ClearWin64.exe with the same link as before.

This contains a new ClearWin64.dll and clrwin$.mod which now includes CORE4 etc. Note that the names of these FTN95 intrinsics have not changed but address arguments with need to be INTEGER*8 for gFortran. Use INTEGER(CW_HANDLE) for code to work under both FTN95 and gFortran.

SETENV.BAT nor GF.BA need to be changed. I have proved the test suite compile with gForrtan fine.

I still do not have 6.3.1 so I am now attempting to get an example of our code to compile in gFortran. As far as I am aware it is FTN77 ( with FTN95 tweaks and extensions ) but am struggling to understand the gForrtan requirements. I need a reference to their spec unless you are able to answer my problems each time I hit them ?

This is our standard approach to head our routines to do with the INCLUDE of COMMON areas, comments and continuation lines :

       SUBROUTINE WMQLIS(NAREA, IRET)
C     ------------------------------------------
C
      INCLUDE 'WINDOWS.INC'
C
      INCLUDE 'MTSURV.INC'
C
      ......ETC 

The WINDOWS.INC file has the following lines :

C
      IMPLICIT REAL*8 (A-H, O-Z)
      IMPLICIT INTEGER*2 (J)
C
      INCLUDE 'WINDOWS.INS', NOLIST
      INCLUDE 'RETURN.INC'
C

and RETURN.INC is :

C
      REAL*8    R8RET
      INTEGER*4 I4RET
      LOGICAL   LOGRET*4, LOGRT2*2
C
      COMMON / RET_CODE / R8RET, I4RET, LOGRET, LOGRT2
C

and the top of MTSURV.INC has :

C
      CHARACTER*252 SURVEY(4)
      CHARACTER TITLE(4)*40
C
      COMMON / COMSRV1 / SURVEY, NSURV1(4), NSURV2(4), TITLE,
     +                   NPTS(4), NFP(4), NHP(4), NSYM(10,4),
......... ETC .......

1. I believe I have to change the Comment C to be !

2. WINDOWS.INC now looks like :

   ! USE mswin$ ! IMPLICIT REAL8 (A-H, O-Z) IMPLICIT INTEGER2 (J) ! INCLUDE 'RETURN.INC' !

3. RETURN.INC looks like :

   ! REAL8 R8RET INTEGER4 I4RET LOGICAL LOGRET4, LOGRT22 ! COMMON / RET_CODE / R8RET, I4RET, LOGRET, LOGRT2 !

4. Changing as per (1) in all remaining INCs gFortran issues the following errors

4(a) Error : Syntax error in data declaration, for the LOGRET*4 in the RETURN.INC file

4(b) Error : Syntax error in COMMON statement, just after the last character on the COMMON / COMSRV1 / line in MTSURV.INC

4(c) Error : Invalid charater in name, pointing at column 7 on the continuation line to 4(b)

Thanks

I have now added the missing FTN95.EXE to the download. Sorry about that.

Please note that you cannot pass ZERO with the 64 bit intrinsics CORE4 etc. CORE4(0) was used to pass a NULL pointer and this must now be handled in a different way.

From your comments above, I would first check that gFortran knows that you are using fixed format Fortran. You can use .for as the file extension or use -ffixed-form on the command line.

Thankyou for 6.3.1 and for compiler recognising our original .for code rather than .f95

Continuing with compiling ( on original code now ) the following errors occur :

Assuming C IMPLICIT REAL8 (A-H, O-Z) IMPLICIT INTEGER2 (J) C

(1) 'If clause [ at (1) ] requires a scalar LOGICAL expression' for both of these lines of code. TEST_BIT$ is a change from the Clearwin TEST_BIT@ function. IDONE is a dimensioned array,

C
                  IF (TEST_BIT$(IDONE, N)) GO TO 230
C
                  IF (BTEST(IDONE, N)) GO TO 230
C

(2) 'Unclassifiable statement [ at (1) ]'.

C
      STDCALL STARTPROGRESS 'StartProgress' (VAL, STRING, VAL, VAL, VAL,
     *                                                         VAL, VAL)
C

StartProgress is one of our Delphi generated DLL entry points. I have placed the DLL in the same ( samples ) folder.

Do I have to append any parameter value to the 'x86_64-w64-mingw32-gfortran' compilation call to recognise our DLL ?

Thanks

Quoted from Steve

(2) 'Unclassifiable statement [ at (1) ]'.

C
      STDCALL STARTPROGRESS 'StartProgress' (VAL, STRING, VAL, VAL, VAL,
     *                                                         VAL, VAL)
C

StartProgress is one of our Delphi generated DLL entry points. I have placed the DLL in the same ( samples ) folder.

Do I have to append any parameter value to the 'x86_64-w64-mingw32-gfortran' compilation call to recognise our DLL ?

If I were you, I would download a copy of Simply Fortran, add DLL-files into project and let IDE handle the external libraries linking mechanics for you.

You also have to change all the FTN95 style STDCALL definitions into an interface using iso_c_binding. If you provide all the datatypes for STARTPROGRESS procedure parameters, I can write you the correct interface as an example.

TEST_BIT@ is an FTN95 intrinsic and is not part of the ClearWin+ library.

According to the FTN95 documentation, the equivalent standard Fortran equivalent is BTEST.

I'll soon try resetting TEST_BIT@ but BTEST also failed ?

Are you suggesting Simply Fortran is yet another alternative to building an application rather than using the Silverfrost tools ? I see SF is based on gFortran, so will it be capable of producing 64 bit ? Will our source still be able to use Clearwin ?

Quoted from Steve

Are you suggesting Simply Fortran is yet another alternative to building an application rather than using the Silverfrost tools ? I see SF is based on gFortran, so will it be capable of producing 64 bit ? Will our source still be able to use Clearwin ?

I use Simply Fortran myself for all the GFortran work. It's got a simple interface, integrated debugger and comes along with the GFortran compiler reference documentation. Building of 64-bit projects is naturally supported and I see no reason why 64-bit Clearwin+ library DLL would not work with it.

If you prefer working with Plato and if it's new version supports building GFortran projects, then you can just add the external DLL's into projects References to handle the imports.

For those with the beta release, the new Plato does indeed support gFortran to provide a 64 bit release but nothing more at the moment.