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
PaulLaidler
Site Admin


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

PostPosted: Fri Mar 01, 2013 7:06 pm    Post subject: Reply with quote

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


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

PostPosted: Fri Mar 01, 2013 9:05 pm    Post subject: Reply with quote

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



Joined: 23 Feb 2007
Posts: 64

PostPosted: Mon Mar 04, 2013 11:27 am    Post subject: Reply with quote

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.

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


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

PostPosted: Mon Mar 04, 2013 2:33 pm    Post subject: Reply with quote

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



Joined: 23 Feb 2007
Posts: 64

PostPosted: Tue Mar 19, 2013 5:47 pm    Post subject: Reply with quote

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


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

PostPosted: Tue Mar 19, 2013 6:21 pm    Post subject: Reply with quote

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


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

PostPosted: Wed Mar 20, 2013 9:13 am    Post subject: Reply with quote

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



Joined: 23 Feb 2007
Posts: 64

PostPosted: Wed Mar 20, 2013 10:14 am    Post subject: Reply with quote

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



Joined: 23 Feb 2007
Posts: 64

PostPosted: Wed Mar 20, 2013 12:35 pm    Post subject: Reply with quote

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


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

PostPosted: Wed Mar 20, 2013 5:43 pm    Post subject: Reply with quote

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



Joined: 23 Feb 2007
Posts: 64

PostPosted: Thu Mar 21, 2013 10:41 am    Post subject: Reply with quote

Thanks, Paul, I have been going round in circles !

I've included your gFortran compiled MOD files but got the following error message when Build'ing in Simply Fortran :

Code:

      USE mswin$                                                       
         1
Fatal Error: Wrong module version '8' (expected '9') for file 'mswin$.mod' opened at (1)


Does this mean you have to compile the MODs in at least an improved version than my gFortran ? [ I am afraid it is not obvious during the compilation what version of gFortran I have ]

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


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

PostPosted: Thu Mar 21, 2013 4:29 pm    Post subject: Reply with quote

I does look like you are using a later version of gFortran.
Are you using the 64 bit gFortran compiler?
If you are then I will try to use the later gFortran for my next upload.
Back to top
View user's profile Send private message
Steve



Joined: 23 Feb 2007
Posts: 64

PostPosted: Thu Mar 21, 2013 4:41 pm    Post subject: Reply with quote

Yes, I am having to use the 64 bit compiler.

Will this be a problem whenever gFortran changes versions ?

Will the next CLEARWIN64.EXE, then, include the updated MODs and the 'new' bit testing/setting routines etc ?

editted 16:02 :-

In the meantime I have attempted to create a Simply Fortran project using the Clrwin.f95 source from the download. [ thereafter I was going to create an individual MOD for each of the other source files ]. This generated loads of errors that went something like :

Code:
Open Watcom Make Version 1.9 (Built on Feb  4 2013)
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
   "C:\Program Files (x86)\Simply Fortran\mingw-w64\bin\gfortran.exe" -c -o "build\clrwin.o" -g  -fdollar-ok -fno-range-check -fno-align-commons -fno-underscoring -Jmodules "..\..\Program Files (x86)\Silverfrost - 6.3.1 - beta gFortran\FTN95\source64\clrwin.f95"
   "C:\Program Files (x86)\Simply Fortran\mingw-w64\bin\gfortran.exe" -o "ClearwinMod.dll" -shared "build\clrwin.o" -LC:/PROGRA~2/SIMPLY~1/MINGW-~1/lib/ -mrtd -static
build\clrwin.o: In function `__clrwin$_MOD_get_files$':
C:\SimplyFortran\ClearwinMod/../../Program Files (x86)/Silverfrost - 6.3.1 - beta gFortran/FTN95/source64/clrwin.f95:3795: undefined reference to `__close_get_next'
C:\SimplyFortran\ClearwinMod/../../Program Files (x86)/Silverfrost - 6.3.1 - beta gFortran/FTN95/source64/clrwin.f95:3801: undefined reference to `__close_get_next'
C:\SimplyFortran\ClearwinMod/../../Program Files (x86)/Silverfrost - 6.3.1 - beta gFortran/FTN95/source64/clrwin.f95:3802: undefined reference to `__get_errno'


If I had to create my own modules from your source what other data files would I need to include with the Clrwin.f95 ?

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



Joined: 16 Feb 2006
Posts: 1660
Location: Sydney

PostPosted: Fri Mar 22, 2013 12:13 am    Post subject: Reply with quote

Paul,

While I have not been involved in the Clearwin_64 discussion, I am interested to persue this when I have the time available to dedicate to this.
Is gFortran the only 64_bit compiler supported ?

My preference is with Intel, which supports faster run times, especially with SSE2 and AVX instructions available. I am using this for coding technique development.

I should point out that most (all) of the code I am using for paid work is running using FTN95. It runs slower but is (hopefully) bug free, thanks to the diagnostics available in FTN95.

John
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Fri Mar 22, 2013 7:28 am    Post subject: Reply with quote

To date 64 bit ClearWin+ has been tested with gFortran and NagFortran but it is designed to work with any Standard conforming Fortran. In particular the bindings that are provided use ISO_C_BINDING whilst the DLL is written in C++.
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 3 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