forums.silverfrost.com

DanRRight

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.

PaulLaidler · Posted: Sat Oct 22, 2016 8:17 am Post subject:

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.

DanRRight · Posted: Sat Oct 22, 2016 9:01 pm Post subject:

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?

PaulLaidler · Posted: Sun Oct 23, 2016 7:46 am Post subject:

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.

mecej4 · Joined: 31 Oct 2006 Posts: 1899

LitusSaxonicum · Posted: Mon Oct 24, 2016 9:05 pm Post subject:

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