Using third party 32bit libraries with 64bit FTN95

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.

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.

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?

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.

Quoted from John-Silver 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:

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

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