Compiling DLLs - 64 bit not allowed?

Hello, everybody,

I've been using FTN95 Personal Edition 8.10 for about a month now, which also marks my beginning with Fortran.

And now I'm stuck with 64-bit DLLs:

When I want to compile a DLL as x64 in Plato, I get an error saying that only 32-bit are allowed. But when I want to link the 32-bit DLL to a x64 project, i get an error saying that a 64-bit DLL is required.

Could somebody please tell me, what to make of this?

Thank you!

It might be a bug in Plato.

A 64 bit dll requires 64 bit object code to be linked using SLINK64.

Have a look at the BuildLog file generated by Plato to see what it is doing for you and make sure that it is calling SLINK64 and that all the .obj files are produced using /64 on the FTN95 command line.

Thanks for your response!

I think so too, because when i execute slink64 in command line mode, it works fine. Although I don't know, what to make of Plato's build log:

FTN95.EXE 'D:\Onedrive\FH\Master\DA\Arbeit\Programmierung\Global_Variables\utilities_parameters.f95' /64 /NO_BANNER /VS7 /DELETE_OBJ_ON_ERROR /ERROR_NUMBERS /UNLIMITED_ERRORS /FPP /CFPP /REF 'D:\Onedrive\FH\Master\DA\Arbeit\Programmierung\DLL_Test\Reusable_Utilities\Utilities_Common\Release\x64\Utilities.dll' /BINARY 'Release\x64\utilities_parameters.obj'

I am not clear as to what is going on here. The /REF to Utilities.dll may not be needed but probably won't do any harm. Also there is no SLINK64 command in the BuildLog.

I would need a simple demo project in order to make further progress.

I'll set up the demo project tomorrow. How can I transer it to you?

You could zip it up, put it on Dropbox and leave a link here or in my message box.

Here's the link to a small dummy project: https://1drv.ms/u/s!AkWmdk4ouK9Fk8R6_qs7s1QZ8VWcqQ

as mentioned in https://forums.silverfrost.com/Forum/Topic/3153 the FORALL statement doesn't work.

Viroxa

An initial inspection indicates that this part of Plato is unfinished. Can you post some code that shows the attempted call to the PURE function?

Hi, Paul,

It's already there:

main.f95 of program.ftn95p line 12 calls 'multiply' from the DLL, producing this error:

D:\Onedrive\FH\Master\DA\Arbeit\Programmierung\Test\Example\main.F95(12) : error 835 - The function MULTIPLY is in a FORALL construct, but does not have the PURE attribute

Thanks for your time inspecting this problem!

Xaver

Xaver

The main program does not know that the function is PURE so an interface must be provided...

PROGRAM example
    IMPLICIT NONE
    INTERFACE
      PURE INTEGER FUNCTION multiply(k)
          INTEGER,INTENT(IN)::k
      END FUNCTION multiply
    END INTERFACE
    INTEGER::irows,nrows=5
	INTEGER,ALLOCATABLE::array(:)
	
    ALLOCATE(array(nrows))
    DO irows=1,nrows
		array(irows)=multiply(irows)    
    ENDDO
    
    FORALL(irows=1:nrows) array(irows)=multiply(irows)

PRINT*,array
END PROGRAM

Thanks for your patience!

Must the interface for each subroutine/function be provided in the module where the according routine is used, or can that be done centrally for all?

Quoted from viroxa

Must the interface for each subroutine/function be provided in the module where the according routine is used, or can that be done centrally for all?

Whether an interface is required or not is governed by the Fortran language rules.

Generally, if the implicit interface is correct, no explicit interface is needed. This is the case for old (Fortran 77 and earlier) subroutines and functions.

If the subroutine/function has USE association, no additional interface is probably needed.

If the subprogram uses any modern Fortran features such as optional arguments, assumed shape array arguments or arguments with attributes, an interface is required.

Thanks for the explanation. Now I see a little bit clearer.

Now that we have looked at a number of features of your program, it occurs to me that FORALL, PURE functions and putting a trivial function in a DLL are all, perhaps, mere distractions.

Each of these features makes the program harder to write, build and debug. It should be clear that none of those features are needed for the simple goal of doubling the elements of a one-dimensional array of reals.

Furthermore, FORALL has been declared 'obsolescent'; see section B.3.13 of http://j3-fortran.org/doc/year/15/15-007.pdf . Language features labeled 'obsolescent' should probably not be used in new code that you write now.

It would be most useful if you would write a description of what you want to do with your ultimate program. What is the true nature of the function that you want to put in a DLL? Why is it necessary to make your code parallel?

As with any engineering project, it is good to assess the various choices available and select a small subset which you then investigate/develop farther, rather than make an injudicious choice now and spend a lot of effort later on getting things to work properly and efficiently.

Thanks for the advice. That simple function only served as a means to show the problems I encountered.

Currently I'm working on the implementation of a 3-node plate element for analysis of multilayered composites.

The overall structure is:

1. Material- / Cross-Section-Input
2. Mesh-Input
3. Calculation of laminate stiffness arrays
4. Calculation of element stiffness arrays
5. Application of loads
6. Solving

1. Regarding DLLs: I wanted to assemble reusable routines in DLLs to have them accessable for other applications (for example: material constant arrays, mathematical utilities, etc.)

2. Regarding FORALL: I didn't know that it's been declared obsolescent, thanks for pointing that out! I used it, because I'm working with up to 4-dimensional arrays, and it seemed more convenient to use FORALL, rather than nested loops or splitting the arrays and looping twice for different routines.

What other option do I have in this matter?

Fortran provides other facilities to do what you used FORALL for; among them are array expressions, array constructors and and array assignments. Your entire code could be rewritten as

PROGRAM example
    IMPLICIT NONE

    INTEGER :: irows, nrows = 5
    INTEGER, ALLOCATABLE :: array(:)

    ALLOCATE(array(nrows))
    array=2*[(irows, irows = 1,nrows)]
    PRINT*,  array
    DEALLOCATE(array)

END PROGRAM

The expression within brackets is an array constructor based on an implied DO loop, and that expression is an array expression even after the multiplication by 2. The statement on that line is an array assignment.

Good to know, thanks! And how could one handle more complex functions?

That would depend on the nature of the function, so it is not easy to give a universal prescription.

You could program your complicated function using simple code at first, get it to produce correct results, and then look into making the code faster by vectorization, parallelization and other methods.

OK, thanks!