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 

Using third party 32bit libraries with 64bit FTN95

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> 64-bit
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 1823
Location: South Pole, Antarctica

PostPosted: Sat Oct 22, 2016 12:41 am    Post subject: Using third party 32bit libraries with 64bit FTN95 Reply with quote

One of few key moments for me in order to switch to 64bit Silverfrost compiler in addition to existence of Debugger and Simpleplot %pl is possibility to use external parallel libraries which incredibly speed up my code execution so that i do not care much if the compiler is fast or slow.

Will my third party parallel linear algebra libraries in the form of LIB files generated by the old Microsoft Fortran and Intel Fortran work with 64bit FTN95?
First one works 100%, second in 50% cases with current 32bit FTN95

If not is there any workarounds? For example there potentially exist options to generate 32bit and 64bit DLL files of these libraries by Intel Fortran. Or same 64bit DLL or LIB files can be generated by GFortran.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat Oct 22, 2016 8:17 am    Post subject: Reply with quote

Existing 32-bit DLLs and static LIBs must be recompiled in 64-bit form before they can be used with 64-bit applications. This is not just for Silverfrost compilers. It is a general rule. It would be possible to get around this by creating a pipe to a 32-bit application running independently but that would be a desperate measure.
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 1823
Location: South Pole, Antarctica

PostPosted: Sat Oct 22, 2016 9:01 pm    Post subject: Reply with quote

As i understand (though did not try) the Clearwin+ is now compatible with any compiler in the market, be it Intel or GFortran etc. How about FTN95 itself? Will it link with IVF or GFortran LIBs or DLLs?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sun Oct 23, 2016 7:46 am    Post subject: Reply with quote

FTN95 links with the Microsoft DLLs and with OpenGL for sure. I haven't tried IVF or gFortran but they will use the same protocol.

64 bit FTN95 uses the same interface syntax as for 32 bit FTN95. STDCALL is no longer applicable but FTN95 just treats STDCALL as an alias for C_EXTERNAL. ISO_C_BINDING has not yet been implemented.
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 820

PostPosted: Mon Oct 24, 2016 6:03 am    Post subject: Reply with quote

For the none-Polish (not even reversible either) users who are not called Mario , i.e. the non-plumbers amongst us Wink what's a pipe (to a 32 bit application) and how does one create one ?
Is there comprehensive documentation on this hidden in some obscure corner of the manuals ?

(Desperate Situations Require Desperate Measures .... said Desperate Dan Wink as he munched on a cowheel pie ! so such a method could be fine and Dandy for those difficult moments !)
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 820

PostPosted: Mon Oct 24, 2016 6:11 am    Post subject: Reply with quote

.... more generally, I think it's safe to say that none of the F compilers will be fully compatible with any of the others simply because they all have their own 'clever' 'extensions' which the others know nothing (or very little) about.
Why would any Co. go out of their way to make their compiler compatible with the opposition, bearing in mind the effort that would be requird to make it so ?
The only exception might be the need if one compiler was the dominant one in the market (I'm thinking pseudo-MS Office here where I/O files need to be essentially readable by competitor suites - look no further for the difficulty of 100% compatability although the advances over recent years have been impressive.) Making executables compatible would no doubt be even more challenging !
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 913

PostPosted: Mon Oct 24, 2016 12:48 pm    Post subject: Re: Reply with quote

John-Silver wrote:
what's a pipe and how does one create one ? Is there comprehensive documentation on this hidden in some obscure corner of the manuals ?

Assuming that this was not just a rhetorical question: A pipe is a contrivance for taking the output of one program and "piping" that into the input of another program. For example:
Code:
prog1 | prog2 > out.txt

The output stream of Prog-1 is "piped" into (the input stream of) Prog-2, and the output stream of Prog-2 is diverted into a bucket called "out.txt".

Pipes became popular with Unix, and were made available on PCs in MSDOS 2.0.

Unlike a pipe carrying a liquid, a software pipe has the ability to hold data, so the supplier and the consumer do not have to run at the same rates.

On a Unix/Linux system, or in Cygwin, try "man pipe" and "man tee".


Last edited by mecej4 on Mon Oct 24, 2016 9:47 pm; edited 1 time in total
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 1794
Location: Yateley, Hants, UK

PostPosted: Mon Oct 24, 2016 9:05 pm    Post subject: Reply with quote

I am somewhat freaked out by the alimentary canal metaphor, since the point of that is to extract something useful en route, and what comes out is what is left.

In practice, the 32 bit stuff could be in program A, and the 64 bit stuff in program B. B could put a load of data in a file, and then start A with a call START_PROCESS@ (or START_PPROCESS@) - although the former would pause B until A was finished. A related file exchange would send the results back to B. It might not introduce a delay if the files stay in the cache, and so write and read at RAM speeds not hard drive speeds.

If A is running at the same time as B (say by being started with the PPROCESS call, you can send a windows message to tell A to look for a file to operate on, and send a message back when it is done. You can start researching this by reading the instructions for the Clearwin+ format code %rm. I could write more if you wanted. A windows message could contain a limited amount of information, if the data sent between A and B is very limited.

Eddie
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 -> 64-bit All times are GMT + 1 Hour
Page 1 of 1

 
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