(j3.2006) Alternative binding label without C interoperability?

[Clune, Thomas L. GSFC-6101]

> On Sep 27, 2016, at 9:19 PM, Cohen Malcolm <malcolm at nag-j.co.jp> wrote:
> 
> I'm not sure what the problem is with normal external procedures here.  If 
> there is a problem with name mangling, surely there will also be problems 
> with other parts of the ABI (argument passing conventions and the like). 

I don?t think so for our use case.   The procedure will always be invoked by the same Fortran compiler that compiled it, albeit via a circuitous route. 

The use of shared object libraries allows some dependencies within complex models to be deferred until runtime rather than at compile time.   At the very least I?m hoping for a significant improvement in compilation time through increased parallelism, but it would also enable runtime configuration of our models that otherwise currently requires compile time changes.   Certainly there are other means to enable the latter, but we are restricted by the use of the ESMF framework.    That framework already provides support to use shared object libraries to register components services, but requires the end user to provide the external binding name.   The only other option for the framework is to directly pass each setServices() procedure as an argument.   (And as per above, the framework is compiled with the same Fortran compiler.)   Without providing all the pertinent details, suffice it to say that the hierarchical design of our model, the latter option requires each component to have compile time dependencies on its children components that could otherwise be deferred until runtime.

> Compilers that have compatibility options (so that things can interoperate 
> with other compilers) usually have those options affect more than just the 
> "name mangling", but how the stack and registers are used, what method is 
> used for passing character argument lengths, dope vector layouts, and so on.
> 
> Furthermore, without linking this binding name to the companion processor, 
> there is no reason for any compiler to produce something that is even the 
> same as that of another compiler.  The standard is able to specify this by 
> explicitly linking it to the companion processor's entity with that name. 
> Without any such entity, there is no way the standard can specify this.

I understand.   But in this case there is no companion processor, so there ought not to be an issue.

I should add that we do have a strategy for extending ESMF to allow an alternate interface for setServices() such that it is interoperable.   We?d be passing C_PTR arguments instead.  Probably will work, and it is a bit less elegant.    


Cheers,

- Tom



> 
> Cheers,
> -- 
> ........................Malcolm Cohen, Nihon NAG, Tokyo. 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3