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 Previous  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
jalih



Joined: 30 Jul 2012
Posts: 187

PostPosted: Tue Feb 26, 2013 8:17 pm    Post subject: Re: Reply with quote

Steve wrote:

(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 ?


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


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

PostPosted: Tue Feb 26, 2013 8:27 pm    Post subject: Reply with quote

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



Joined: 23 Feb 2007
Posts: 73

PostPosted: Tue Feb 26, 2013 11:31 pm    Post subject: Reply with quote

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



Joined: 30 Jul 2012
Posts: 187

PostPosted: Wed Feb 27, 2013 6:41 am    Post subject: Re: Reply with quote

Steve wrote:

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


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

PostPosted: Wed Feb 27, 2013 9:21 am    Post subject: Reply with quote

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



Joined: 23 Feb 2007
Posts: 73

PostPosted: Wed Feb 27, 2013 10:43 am    Post subject: Reply with quote

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.

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


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

PostPosted: Wed Feb 27, 2013 3:08 pm    Post subject: Reply with quote

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



Joined: 23 Feb 2007
Posts: 73

PostPosted: Wed Feb 27, 2013 6:06 pm    Post subject: Reply with quote

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


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

PostPosted: Thu Feb 28, 2013 9:51 am    Post subject: Reply with quote

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


Last edited by PaulLaidler on Fri Mar 01, 2013 7:25 am; edited 1 time in total
Back to top
View user's profile Send private message
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Thu Feb 28, 2013 1:33 pm    Post subject: Reply with quote

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 ?

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


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

PostPosted: Thu Feb 28, 2013 11:58 pm    Post subject: Reply with quote

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

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


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

PostPosted: Fri Mar 01, 2013 8:35 am    Post subject: Reply with quote

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

Code:
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


Last edited by PaulLaidler on Fri Mar 01, 2013 8:59 pm; edited 1 time in total
Back to top
View user's profile Send private message
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Fri Mar 01, 2013 10:03 am    Post subject: Reply with quote

Thanks, Paul, I'll look into it.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Mar 01, 2013 10:31 am    Post subject: Reply with quote

You will find that IOR is more direct than the combination of IBCLR and IBSET.
Back to top
View user's profile Send private message
Steve



Joined: 23 Feb 2007
Posts: 73

PostPosted: Fri Mar 01, 2013 4:23 pm    Post subject: Reply with quote

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.
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 Previous  1, 2, 3, 4  Next
Page 2 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