forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Converting 32 bit to 64 bit
Goto page 1, 2, 3, 4  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Thu Feb 21, 2013 2:22 pm    Post subject: Converting 32 bit to 64 bit Reply with quote

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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Thu Feb 21, 2013 6:12 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Thu Feb 21, 2013 9:02 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Fri Feb 22, 2013 11:46 am    Post subject: Reply with quote

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

Example of the LOC and CCORE1 usage

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)

Other CORE examples

We also use CORE2,

CALL MOVE@(CORE2(ILP), ILPRM(1), 4Cool

and CORE4

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

Thanks
Back to top
View user's profile Send private message
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Fri Feb 22, 2013 2:43 pm    Post subject: Reply with quote

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

Thanks once more
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Feb 22, 2013 3:29 pm    Post subject: Reply with quote

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...

Code:
extern "C" float fcore4(long long pVal)
{
  float* p = (float*)pVal;
  return *p;
}


In the same project a Fortran file contains...

Code:
      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.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Feb 22, 2013 3:37 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message AIM Address
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Fri Feb 22, 2013 4:37 pm    Post subject: Reply with quote

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 ?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Fri Feb 22, 2013 4:53 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Fri Feb 22, 2013 5:58 pm    Post subject: Reply with quote

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 ?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Sat Feb 23, 2013 8:31 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Feb 25, 2013 11:33 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Mon Feb 25, 2013 5:20 pm    Post subject: Reply with quote

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 :

Code:

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


The WINDOWS.INC file has the following lines :

Code:

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 :

Code:

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 :

Code:

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 :

Code:

!
      USE mswin$
!
      IMPLICIT REAL*8 (A-H, O-Z)
      IMPLICIT INTEGER*2 (J)
!
      INCLUDE 'RETURN.INC'
!


3) RETURN.INC looks like :

Code:

!
      REAL*8    R8RET
      INTEGER*4 I4RET
      LOGICAL   LOGRET*4, LOGRT2*2
!
      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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Feb 26, 2013 9:11 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Tue Feb 26, 2013 1:33 pm    Post subject: Reply with quote

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
Code:
C
      IMPLICIT REAL*8 (A-H, O-Z)
      IMPLICIT INTEGER*2 (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,
Code:
C
                  IF (TEST_BIT$(IDONE, N)) GO TO 230
C
                  IF (BTEST(IDONE, N)) GO TO 230
C


(2) "Unclassifiable statement [ at (1) ]".
Code:
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
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+ All times are GMT + 1 Hour
Goto page 1, 2, 3, 4  Next
Page 1 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group