Converting 32 bit to 64 bit

Thanks, jalih, that sounds encouraging.

We do not use Plato so it will be a learning curve to get to know SF's IDE. Certainly seeing how Delphi's IDE works it should be a powerful tool.

Paul, I suspect if I cannot get gf.bat ( amended for .for source code ) to compile TEST_BIT@ and BTEST then SF is also not going to compile ? I am still getting the same compile error messages.

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.

What is an alternative way, please ?

Any mileage in how to handle STDCALL in gFortran ? I guess the $MODs must be handling the interface, but how do we get our .for source code to do the same ?

Thanks

BTEST is a standard Fortran intrinsic so you should be able to get it to compile with FTN95 and gFortran. Look up the function in the help file and create a separate short test program to see how the function works.

CORE4(0) is often used in FTN95 code to pass a NULL pointer to an external function that is coded in C. The way in which you translate this for gFortran will depend on the function and the type of the pointer that you want to pass. It might be quicker if you send me an example but if you have a large number of them then you may need expert help.

STDCALL is not relevant for 64 bit code so you just leave it out. Have a look at the source code in Silverfrost\FTN95\source64 in order to see how interfaces are constructed.

Contrary to the FTN95 documentation, I found that neither of the parameters for BTEST can be dimensional. The same rules apply for gFortran. As such I have always been okay with the function. The confusion was when I substituted BTEST for TEST_BIT@ when this was using an aray, in order to get bit testing working in the gFortran compiler.

As for TEST_BIT@ I cannot see an equivalent in gFortran. I guess this is why the compiler issued a syntax error ?

I need to prove the new gFortran compiler - to us - works in 32 bit mode. Is this what the supplied gf.bat produces or does gf.bat compile in 64 bit mode. From your comment about STDCALL, if we want to compile gFortran in 32 bit then I guess we do indeed require the ISO_C_BINDING equivalent of STDCALL ? I have had a look at the supplied .f95 routines and attempted my own. The text here in is a .f95 the compilation of which is okay to mix as a linked project with compiled .for source ?

My attempt at ISO_C_BINDING ! MODULE PROGRESS CONTAINS SUBROUTINE STARTPROGRESS(VAL1, STRING, VAL2, VAL3, VAL4, VAL5, VAL6) BIND(C,NAME='StartProgress') USE ISO_C_BINDING CHARACTER (C_CHAR) :: STRING INTEGER (C_INT) :: VAL1, VAL2, VAL3, VAL4, VAL5, VAL6 END SUBROUTINE STARTPROGRESS ! SUBROUTINE UPDATEPROGRESS(VAL) BIND(C,NAME='UpdateProgress') USE ISO_C_BINDING INTEGER (C_INT) :: VAL END SUBROUTINE UPDATEPROGRESS ! SUBROUTINE ENDPROGRESS() BIND(C,NAME='EndProgress') USE ISO_C_BINDING END SUBROUTINE ENDPROGRESS ! ENDMODULE PROGRESS !

The only example we have in the use of CORE4() is the one I gave before where an array value is being assigned thru the use of CORE4(). So the concern you have is if any of the array values are zero ?

Thanks[/code]

gf.bat is written for 64 bit gFortran. I don't have any experience with the 32 bit compiler and it may not be included in our download.

The limitation on CORE4 is when the argument (i.e. the address) is zero. This is not the case in your example so you don't need to bother with this limitation.

See below for more information about TEST_BIT@.

Thanks, Paul

Not sure I understand the example of TEST_BIT@. My understanding of this function is to set a bit at position POS within the array IA. So POS could go beyond the 1st, 2nd, 3rd...nth INTEGER element within the array. The same concept goes for the SET_BIT@ and CLEAR_BIT@ functions.

I have written my own versions of these functions, but there must be a way of identifying the SIZE of the integer array without the function call having to specify it ?

      LOGICAL*4 FUNCTION TEST_BIT(VAL,LENF,NTH)
C     --------------------------------------------
C
C     Test bit NTH within an INTEGER*4 array.
C
      INTEGER*4 VAL(LENF), NTH
C
      N1 = (NTH-1)/32
      N2 = NTH-(N1*32)
      N1 = N1 + 1
C
      TEST_BIT = .FALSE.
      IF (BTEST(VAL(N1),N2)) TEST_BIT = .TRUE.
C
      RETURN
      END

It was more sophisticated than I thought. This sample gives the essence...

program btst
integer(2)::ia(5)
integer i,j,pos,bsize
logical r
ia = 47
ia(4) = 0
pos = 50
call set_bit@(ia,pos)
r = test_bit@(ia,pos)
print*,r,ia
call clear_bit@(ia,pos)
r = test_bit@(ia,pos)
print*,r,ia
!!!!!!
print*
ia = 47
ia(4) = 0
pos = 50
bsize = bit_size(ia)
i = pos/bsize+1
j = mod(pos,bsize)
ia(i) = ia(i) + ibset(ia(i),j)
r = btest(ia(i),j)
print*,r,ia
ia(i) = ibclr(ia(i),j)
r = btest(ia(i),j)
print*,r,ia
end

Remove test_bit@ etc when compiling with gFortran.

But this is still not quite right! More to follow later when my head is clear.

Hopefully this is right now but check it out and adapt it to your needs

program btst
integer(2)::ia(5)
integer i,j,pos,bsize
logical r
ia = 47
ia(4) = 0
pos = 50
call set_bit@(ia,pos)
r = test_bit@(ia,pos)
print*,r,ia
call clear_bit@(ia,pos)
r = test_bit@(ia,pos)
print*,r,ia
!!!!!!
print*
ia = 47
ia(4) = 0
pos = 50
bsize = bit_size(ia)
i = pos/bsize+1
j = mod(pos,bsize)
ia(i) = ibset(ia(i),j)                  !equivalent to set_bit@
r = btest(ia(i),j)                      !equivalent to test_bit@
print*,r,ia
ia(i) = ibclr(ia(i),j)                  !equivalent to clear_bit@
r = btest(ia(i),j)
print*,r,ia
end

Thanks, Paul, I'll look into it.

You will find that IOR is more direct than the combination of IBCLR and IBSET.

Sorry, Paul, bit confused here. A bit can only be 0 or 1, ie a CLEAR or a SET, so what's the over complicaion of IBCLR plus IBSET or even your later suggstion of IOR ?

Anyhow, the whole point of my routine example was to create a module that would handle the bit test without knowledge of the original defined (array) variable. Thence, a single complete replacement for the 1000 calls to TEST_BIT@ in our code. But I could not get LBOUND and UBOUND to work within my coded suggestion to find out the length of the array. After all I do not want to set a bit if the calculated nth integer array element is beyond the bounds of the array. Hence the input parameter LENF. Admittedly, I should have checked N1 against this value.

An added preference is for the array KIND not to be explicitly defined. This indeed would require the use of BIT_SIZE

Therefore, at the moment the use of my routine would have to be constrained to INTEGER*4 arrays and every call would need to include the array length. A real nightmare to amend. Which goes to show the 3 bit handling @ FTN95 extensions are very powerful.

The purpose of my sample code was to show what is needed in your routines that replace TEST_BIT@ etc. When I get a minute I will write the routines and add them to the library.

logical function test_bit$(ia, pos)
integer,parameter::k = selected_int_kind(4)
integer(k)::pos,i,ia(*)
integer(k),parameter::bsize = bit_size(ia)
i = 1 + pos/bsize
test_bit$ = btest(ia(i), mod(pos,bsize))
end function

subroutine set_bit$(ia, pos)
integer,parameter::k = selected_int_kind(4)
integer(k)::pos,i,ia(*)
integer(k),parameter::bsize = bit_size(ia)
i = 1 + pos/bsize
ia(i) = ibset(ia(i), mod(pos,bsize))
end subroutine

subroutine clear_bit$(ia, pos)
integer,parameter::k = selected_int_kind(4)
integer(k):: pos,i,ia(*)
integer(k),parameter::bsize = bit_size(ia)
i = 1 + pos/bsize
ia(i) = ibclr(ia(i), mod(pos,bsize))  
end subroutine

Thanks, Paul, 'selected_int_kind' was obviously the missing link in my knowledge. On the solution you have proposed might it be safer to only permit the bit work knowing that the value 'pos' would be within the bound of the array ?

Moving on, if I may, to the point you raised about the replacement of STDCALL when going up to 64 bit.

STDCALL is not relevant for 64 bit code so you just leave it out. Have a look at the source code in Silverfrost\FTN95\source64 in order to see how interfaces are constructed

I've looked at mswinapi.f95 example. Is not the ISO_C_BINDING the equivalent of the STDCALLs that win32api.ins ? My attempt was to code the interfaces using ISO_C_BINDING as the replacement for STDCALL and not to 'just leave it out'. Did my attempt look reasonable ? Should the source example be coded as .f95 ?

Thanks

My guess is that, when you use ISO_C_BINDING for 32 bit code, you will still need to distinguish between the STDCALL and cdecl calling conventions whilst for 64 bit code there is only one calling convention (hence it does not have a name).

I would need to look it up but I would expect the default calling convention within (32 bit) ISO_C_BINDING to be compiler dependent. If this is the case then (for 32 bit code) you may need to add STDCALL as an additional attribute. Where STDCALL is needed for 32 bit ISO_C_BINDING, for 64 bit code you simply leave it out.

As Jalih points out, if I'm wanting to create a 32 bit version using Simply Fortan in order to prove gFortran working on our code I do need to have a version of CLRWIN, for example, that defines ISO_C_BINDING.

With this in mind I took your 64 bit code CLRWIN.F95 and attempted to compile it with gFortran.

There were many compilation errors 'undefined reference to' functions such as ___close_get_next and __get_errno. Your named$ functions are defined okay but these are the C bind routine names. [ compiling in 32 bit or 64 bit made no difference ].

What are these, Paul, and how would I get gFortran to accept compilatikon of the CLRWIN.F95 ?

I wonder, has anyone experienced converting projects in Silverfrost/Clearwin+ and successfully ported them across to gFortran ? Only that I am having extreme difficulties. Our actual source code is very straight forward fixed format .FOR and yet trying to get the Clearwin+ environment accepted into gForrtan is a nightmare.

There is currently no access to ClearWin+ from 32 bit gFortran unless you want to try using the original salflibc.dll but that could raise all kinds of problems.

You already have 64 bit gFortran compiled copies of the modules but if you want to compile them again you will need to use the supplied gFortran version. It looks like you are trying to use the FTN95 code which will not work. In gFortran form uses ISO_C_BINDING.

If you are using the correct code then you will need to compile using 64 bit gFortran and link using clearwin64.dll or (if you prefer) clearwin64.a.

Steve

To be fair, your problems may not be related to ClearWin+. There are at least three other significant issues involved in your case...

1. the need to port an associated Delphi DLL to 64 bit.

2. the use of FTN95 LOC and CORE routines.

3. the use of FTN95 TEST_BIT@ and SET_BIT@ routines.

Okay, so it is 64 bit only then !

Once we have established our 64 bit compiled version of our Delphi can we be assured that the set of CORE and set of TEST_BIT routines will be in the 64 bit Clearwin+ dll ?

Thanks

I am testing a much simpler project that does not rely on our Delphi dll and am indeed building this new project as 64 bit.

I have included the clearwin64.dll as part of the project in Simply Fortran and the clearwin routine Clearwin_String$ is not being recognised as a function.

Do I have to state all the clearwin functions as External ( with their appropriate data declaration ) within the calling routine ?

Thanks

I plan to update the beta download immediately after the next full release of FTN95.

All of the 64 bit ClearWin+ functions are declared in clrwin.f95 and this can be found in FTN95\source64.

But these files have already been compiled for gFortran users. The MOD files can be found in FTN95\include\gFortran and all the object code for the modules is build into a DLL called ClearWin64f.dll.

This information can be found in the readme file called ClearWin64.txt that is located in C:\gFortran\samples (assuming you have used the default folder for the gFortran download from Silverfrost).