[SciPy-Dev] [fwrap-users] Work on fwrap and SciPy

[Dag Sverre Seljebotn]

On 11/04/2010 04:31 AM, Kurt Smith wrote:
> On Wed, Nov 3, 2010 at 7:58 PM, David<david at silveregg.co.jp>  wrote:
>    
>> On 11/04/2010 06:00 AM, Kurt Smith wrote:
>>
>>      
>>>>    c) fwrap does not support g77, only Fortran 90 compilers like
>>>> gfortran/ifort etc. For the purposes of the .NET port this is likely to be
>>>> good enough. Before a merge with the main CPython branch one must perhaps
>>>> look into implementing g77 support in fwrap. I know that David C. at least
>>>> earlier stated that g77 support is not going away anytime soon. Feedback on
>>>> this welcome.
>>>>          
>> G77 is still the "standard" fortran compiler on significant platforms
>> (mingw and RHEL/Centos). Could you quickly explain why g77 is not usable
>> with fwrap ? Would it take a long time to add support (if that is even
>> possible) ?
>>      

Just to give everyone a taste, here's an example of modern Fortran 
interopability:

function add(x, y) bind(c)
     use iso_c_binding
     real(c_double), value :: x, y
     real(c_double) :: add
     add = x + y
end function add

This function is callable from C as "double add(double x, double y)". In 
particular, "bind(c)" turns off name mangling (and allow setting a 
different link symbol name through another parameter), and the "value" 
attribute means to not pass by reference. This is all standard across 
modern compilers. Essentially, modern Fortran compilers allow your 
Fortran code to be callable just as if it was C code.

The problem of interopability is much worse with Fortran 90/95/2003 than 
Fortran 77 though. E.g., Fortran 90 can pass arrays with shape and 
strides implicitly being passed along, something that has absolutely no 
standard binary interface between compilers. This is one of the main 
problems that fwrap solves.

With Fortran 77, it is much easier to rely on de facto 
standards/assumptions and do some probing.

> ...not *currently* usable.  Fwrap's fortran-C wrappers use features
> defined in the 2003 standard that make it easy to generate portable
> wrapping code.  These features allow wrapping of fortran
> 90/95-specific constructs.
>
> g77 support is certainly possible, given sufficient effort.  I am in
> favor of it, but someone else will have to do it (I'm happy to pitch
> in, of course).  It will require a good deal of work that I can't
> justify given my requirements for the tool.
>    

If all goes well, I'm hoping to have time for this (no promises though, 
as it is kind of low priority with respect to the .NET port).

However, given that I have such time available, then if SciPy instead 
starts requiring Fortran 90 compiler, my time could be more profitably 
spent on more useful stuff :-)

I think the big questions here are
  a) What time scales are we looking at here...in two years time, 
relying on a modern gfortran may be less of an issue.
  b) Is there a case to move SciPy to Fortran 90 anyway (because one 
wants to include scientific code written in Fortran 90?)

My feeling is that gfortran 4.2 compatibility is rather out of the 
question though, as it would require another set of special cases for a 
compiler that is at least soon out-dated.

Dag Sverre