View previous topic :: View next topic |
Author |
Message |
Steve
Joined: 23 Feb 2007 Posts: 73
|
Posted: Thu Feb 21, 2013 2:22 pm Post subject: 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 |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7930 Location: Salford, UK
|
Posted: Thu Feb 21, 2013 6:12 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7930 Location: Salford, UK
|
Posted: Thu Feb 21, 2013 9:02 pm Post subject: |
|
|
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 |
|
|
Steve
Joined: 23 Feb 2007 Posts: 73
|
Posted: Fri Feb 22, 2013 11:46 am Post subject: |
|
|
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), 4
and CORE4
DO I = 0, INFOEB(15)-1
CORE4(INFOEB(17)+I*4) = IPAL(NDPCOL(NCOL))
ENDDO
Thanks |
|
Back to top |
|
|
Steve
Joined: 23 Feb 2007 Posts: 73
|
Posted: Fri Feb 22, 2013 2:43 pm Post subject: |
|
|
Paul, I presume that XOR and AND are equivalent to the f90 IEOR and IAND intrinsics ?
Thanks once more |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7930 Location: Salford, UK
|
Posted: Fri Feb 22, 2013 3:29 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7930 Location: Salford, UK
|
Posted: Fri Feb 22, 2013 3:37 pm Post subject: |
|
|
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 |
|
|
Steve
Joined: 23 Feb 2007 Posts: 73
|
Posted: Fri Feb 22, 2013 4:37 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7930 Location: Salford, UK
|
Posted: Fri Feb 22, 2013 4:53 pm Post subject: |
|
|
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 |
|
|
Steve
Joined: 23 Feb 2007 Posts: 73
|
Posted: Fri Feb 22, 2013 5:58 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7930 Location: Salford, UK
|
Posted: Sat Feb 23, 2013 8:31 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7930 Location: Salford, UK
|
Posted: Mon Feb 25, 2013 11:33 am Post subject: |
|
|
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 |
|
|
Steve
Joined: 23 Feb 2007 Posts: 73
|
Posted: Mon Feb 25, 2013 5:20 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7930 Location: Salford, UK
|
Posted: Tue Feb 26, 2013 9:11 am Post subject: |
|
|
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 |
|
|
Steve
Joined: 23 Feb 2007 Posts: 73
|
Posted: Tue Feb 26, 2013 1:33 pm Post subject: |
|
|
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 |
|
|
|