[SciPy-Dev] [fwrap-users] Work on fwrap and SciPy
Dag Sverre Seljebotn
Thu Nov 4 03:42:33 CDT 2010
On 11/04/2010 04:31 AM, Kurt Smith wrote:
> On Wed, Nov 3, 2010 at 7:58 PM, David<email@example.com> 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
function add(x, y) bind(c)
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.
More information about the SciPy-Dev