|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
jalih
Joined: 30 Jul 2012 Posts: 196
|
Posted: Tue Feb 26, 2013 8:17 pm Post subject: Re: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Tue Feb 26, 2013 8:27 pm Post subject: |
|
|
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 |
|
|
Steve
Joined: 23 Feb 2007 Posts: 73
|
Posted: Tue Feb 26, 2013 11:31 pm Post subject: |
|
|
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 |
|
|
jalih
Joined: 30 Jul 2012 Posts: 196
|
Posted: Wed Feb 27, 2013 6:41 am Post subject: Re: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Wed Feb 27, 2013 9:21 am Post subject: |
|
|
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 |
|
|
Steve
Joined: 23 Feb 2007 Posts: 73
|
Posted: Wed Feb 27, 2013 10:43 am Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Wed Feb 27, 2013 3:08 pm Post subject: |
|
|
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 |
|
|
Steve
Joined: 23 Feb 2007 Posts: 73
|
Posted: Wed Feb 27, 2013 6:06 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Thu Feb 28, 2013 9:51 am Post subject: |
|
|
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 |
|
|
Steve
Joined: 23 Feb 2007 Posts: 73
|
Posted: Thu Feb 28, 2013 1:33 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Thu Feb 28, 2013 11:58 pm Post subject: |
|
|
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 |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Fri Mar 01, 2013 8:35 am Post subject: |
|
|
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 |
|
|
Steve
Joined: 23 Feb 2007 Posts: 73
|
Posted: Fri Mar 01, 2013 10:03 am Post subject: |
|
|
Thanks, Paul, I'll look into it. |
|
Back to top |
|
|
PaulLaidler Site Admin
Joined: 21 Feb 2005 Posts: 7932 Location: Salford, UK
|
Posted: Fri Mar 01, 2013 10:31 am Post subject: |
|
|
You will find that IOR is more direct than the combination of IBCLR and IBSET. |
|
Back to top |
|
|
Steve
Joined: 23 Feb 2007 Posts: 73
|
Posted: Fri Mar 01, 2013 4:23 pm Post subject: |
|
|
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 |
|
|
|
|
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
|