Fortran 90 modules suck for portability- why use them? - Fortran

This is a discussion on Fortran 90 modules suck for portability- why use them? - Fortran ; Hi fellow Fortran users (old and new)! I am new to Fortran but not to programming in general. I started to program more seriously Fortran just a couple of months ago and now I have come up to a cross ...

+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast
Results 1 to 10 of 37

Fortran 90 modules suck for portability- why use them?

  1. Default Fortran 90 modules suck for portability- why use them?

    Hi fellow Fortran users (old and new)!

    I am new to Fortran but not to programming in general. I started to
    program more seriously Fortran just a couple of months ago and now I
    have come up to a cross section where I need some help to understand
    the design of Fortran 90.

    I have seen some serious issues (yes, strong word) with Fortran 90
    modules. The binary compatibility between different compilers - even
    on the same architecture - is zero. Also they create a terrible mess
    in the Make scripts. I just cannot understand why Fortran 90 thought
    there was a need to reinvent the wheel - and make a terrible work
    while doing so?

    Let's look at the test module testmod.f90:
    MODULE TESTMOD
    INTEGER :: X
    CONTAINS
    SUBROUTINE COMPUTE
    END SUBROUTINE
    END MODULE TESTMOD

    Between the three different compilers I have available I see the
    following difference in the object files:

    gfortran 4.2
    00000000 T __testmod__compute
    00000000 B __testmod__x

    Intel Fortran 9.1
    00000000 T testmod._
    00000002 T testmod_mp_compute_
    00000004 C testmod_mp_x_

    Sun studio 12
    00000000 T testmod.compute_
    00000000 B testmod.x_
    00000000 D testmod_

    Also the .mod file is different. <sarcasm>The new Fortran 2003
    standard talks about C integration. How about to start with Fortran <-
    > Fortran integration? </sarcasm>


    This means that you cannot compile a library with say gfortran and use
    it in any other compiler.

    If you avoid using Fortran modules you can get something that is
    binary compatible and usable between the three compilers I have
    available and have also tested with. I have [1] a small example of how
    to write "module code" without using modules. It boils down to using
    INCLUDE instead. There are some negativisms with not using MODULES as
    well but not as many.


    Leading researchers is using Fortran 95 [2] with modules I guess I
    just have to bend over and recognize that this is broken but nobody
    but me seems to care about it. Also, if you look at the BLAS95
    proposal routines, you see lot's of dangerous code. You see unsafe
    EXTERN keywords. I would though out modules and replace it with type
    checking any day of the week (Do not confuse modules with
    interfaces.).

    I think Fortran 90 has lot's of nice features which I think is
    essential to a modern programming language. I know I don't have to
    follow everyone else and use MODULES. I don't even have to use Fortran
    90. But since so many are choosing to use modules and seems fine with
    that - where did you dispose of the bodies of those who questioned it?

    Thanks for your comments. I would very very much like to hear what you
    have to say about these things.

    [1] http://na37.nada.kth.se/mediawiki/in..._the_seventies
    [2] http://www.cs.umd.edu/~stewart/matran/Matran.html

    Cheers,
    --
    Henrik Holst, Sweden
    http://www.csc.kth.se/~holst/contact.shtml


  2. Default Re: Fortran 90 modules suck for portability- why use them?

    Hello Henrik,

    henrikholst80 wrote:
    > Hi fellow Fortran users (old and new)!
    >
    > I am new to Fortran but not to programming in general. I started to
    > program more seriously Fortran just a couple of months ago and now I
    > have come up to a cross section where I need some help to understand
    > the design of Fortran 90.
    >
    > I have seen some serious issues (yes, strong word) with Fortran 90
    > modules. The binary compatibility between different compilers - even
    > on the same architecture - is zero.


    Name mangling issues are a natural consequence of the additional
    conceptual power (e.g., object based programming, encapsulation)
    provided by modules. C++ has the same issues here, although there
    may be more efforts to keep compatibility here (also due to g++
    having been around for a long time!). Also note that even in Fortran
    77 there were limits to binary compatibility (I/O).

    > Also they create a terrible mess
    > in the Make scripts.


    There are scripts which can generate Make dependencies automagically
    for you.

    > I just cannot understand why Fortran 90 thought
    > there was a need to reinvent the wheel - and make a terrible work
    > while doing so?
    >
    > Let's look at the test module testmod.f90:
    > MODULE TESTMOD
    > INTEGER :: X
    > CONTAINS
    > SUBROUTINE COMPUTE
    > END SUBROUTINE
    > END MODULE TESTMOD
    >
    > Between the three different compilers I have available I see the
    > following difference in the object files:
    >
    > gfortran 4.2
    > 00000000 T __testmod__compute
    > 00000000 B __testmod__x
    >
    > Intel Fortran 9.1
    > 00000000 T testmod._
    > 00000002 T testmod_mp_compute_
    > 00000004 C testmod_mp_x_
    >
    > Sun studio 12
    > 00000000 T testmod.compute_
    > 00000000 B testmod.x_
    > 00000000 D testmod_
    >
    > Also the .mod file is different. <sarcasm>The new Fortran 2003
    > standard talks about C integration. How about to start with Fortran <-
    >> Fortran integration? </sarcasm>

    >
    > This means that you cannot compile a library with say gfortran and use
    > it in any other compiler.
    >
    > If you avoid using Fortran modules you can get something that is
    > binary compatible and usable between the three compilers I have
    > available and have also tested with. I have [1] a small example of how
    > to write "module code" without using modules. It boils down to using
    > INCLUDE instead. There are some negativisms with not using MODULES as
    > well but not as many.


    For large scale and object based programming or library design, using "include"
    will not do the job. Note in particular that
    * distinctive types are generated per include, as opposed to modules.
    This makes e.g. passing objects of a type to an external subroutine impossible.
    * encapsulation features are *only* available for modules

    >
    >
    > Leading researchers is using Fortran 95 [2] with modules I guess I
    > just have to bend over and recognize that this is broken but nobody
    > but me seems to care about it. Also, if you look at the BLAS95
    > proposal routines, you see lot's of dangerous code. You see unsafe
    > EXTERN keywords. I would though out modules and replace it with type
    > checking any day of the week (Do not confuse modules with
    > interfaces.).
    >
    > I think Fortran 90 has lot's of nice features which I think is
    > essential to a modern programming language. I know I don't have to
    > follow everyone else and use MODULES. I don't even have to use Fortran
    > 90. But since so many are choosing to use modules and seems fine with
    > that - where did you dispose of the bodies of those who questioned it?
    >
    > Thanks for your comments. I would very very much like to hear what you
    > have to say about these things.
    >
    > [1] http://na37.nada.kth.se/mediawiki/in..._the_seventies
    > [2] http://www.cs.umd.edu/~stewart/matran/Matran.html
    >
    > Cheers,
    > --
    > Henrik Holst, Sweden
    > http://www.csc.kth.se/~holst/contact.shtml
    >

    Regards

    Reinhold

  3. Default Re: Fortran 90 modules suck for portability- why use them?

    In article <4697D5A2.8050300@lrz.de>, Reinhold Bader <Bader@lrz.de> wrote:

    > C++ has the same issues here, although there
    >may be more efforts to keep compatibility here


    Well, there are a lot of system libraries for C++, so for example on
    Linux, gcc and Intel and PathScale all have the same mangling. You
    can't have a viable compiler otherwise.

    In the Fortran77 world, gfortran isn't even g77 compatible. So
    PathsScale, which was g77 compatible for name mangling (but not the
    I/O library), got burned when gfortran decided to mangle names
    differently by default. Oh well.

    And for the Fortran 9X world, well, there was obvious choice to
    imitate.

    -- g


  4. Default Re: Fortran 90 modules suck for portability- why use them?


    Greg Lindahl wrote:
    > In article <4697D5A2.8050300@lrz.de>, Reinhold Bader <Bader@lrz.de> wrote:
    >
    >> C++ has the same issues here, although there
    >> may be more efforts to keep compatibility here

    >
    > Well, there are a lot of system libraries for C++, so for example on
    > Linux, gcc and Intel and PathScale all have the same mangling. You
    > can't have a viable compiler otherwise.
    >
    > In the Fortran77 world, gfortran isn't even g77 compatible. So
    > PathsScale, which was g77 compatible for name mangling (but not the
    > I/O library), got burned when gfortran decided to mangle names
    > differently by default. Oh well.


    Admittedly, it is not only the name mangling but also the module
    information file structure that is an issue. However the advantage
    of not requiring a preprocessor more than outweighs the disadvantage
    in my opinion.

    Also note the variance in OP's posting: Portability and
    binary compatibility are two different items. The former to my
    knowledge concerns itself with achieving the same results
    starting out from a given source code. binary compatibility is
    a much stronger requirement.

    >
    > And for the Fortran 9X world, well, there was obvious choice to
    > imitate.
    >
    > -- g
    >


  5. Default Re: Fortran 90 modules suck for portability- why use them?

    <henrikholst80> wrote:

    > I have seen some serious issues (yes, strong word) with Fortran 90
    > modules. The binary compatibility between different compilers - even
    > on the same architecture - is zero.


    All this has almost nothing to do with modules as a language design
    issue. Binary compatibility between different compilers, even on the
    same architecture, has always been a serious issue long before modules.
    In limitted circumstances, you can sometimes make it work, but the
    problems are great.

    While binary compatibility issues aren't the top FAQ here, they
    certainly are on it. People are continually asking about problems with
    getting a library that was compiled for one compiler to work with a
    different one - sometimes even with a different version of the same
    vendor's compiler. This happens regardless of whether modules are
    involved or not.

    Yes, modules add some extra issues, but if you are using binary
    compatibility as a major means of evaluating language features, then I
    think you will find it a pretty inadequate measure for most purposes.

    You mention C interop. Although you label it as sarcasm, I'd say it
    shows that you are not very familliar with the C interop stuff. I might
    note that the C interop features specifically are designed to also
    facilitate interoperation with other languages. That does include, for
    example, Fortran. It would depend on a vendor wanting to support it, but
    the C interop stuff can be used to interoperate with such things as
    other Fortran compilers. This was an intentional part of the design.

    --
    Richard Maine | Good judgement comes from experience;
    email: last name at domain . net | experience comes from bad judgement.
    domain: summertriangle | -- Mark Twain

  6. Default Re: Fortran 90 modules suck for portability- why use them?

    henrikholst80 wrote:
    > Hi fellow Fortran users (old and new)!
    >
    > I am new to Fortran but not to programming in general. I started to
    > program more seriously Fortran just a couple of months ago and now I
    > have come up to a cross section where I need some help to understand
    > the design of Fortran 90.
    >
    > I have seen some serious issues (yes, strong word) with Fortran 90
    > modules. The binary compatibility between different compilers - even
    > on the same architecture - is zero.


    Yeah, so? I use 4 different compilers on my linux box for testing. For swapping out
    libraries and module files, I use a simple script.

    Are you also rankled when the code you compiled on your SGI doesn't run on your Sun? Or
    IBM? Or HP? Or any of the vice versas?

    > Also they create a terrible mess
    > in the Make scripts.


    My makefiles look exactly the same as do my dependency lists compared to my f77 days. (I
    don't use *.mods as dependencies in suffix rules, just *.o and *.f90,*.F90)

    And anyway, nobody generates dependency lists by hand anymore. )


    > I just cannot understand why Fortran 90 thought
    > there was a need to reinvent the wheel - and make a terrible work
    > while doing so?
    >
    > Let's look at the test module testmod.f90:
    > MODULE TESTMOD
    > INTEGER :: X
    > CONTAINS
    > SUBROUTINE COMPUTE
    > END SUBROUTINE
    > END MODULE TESTMOD
    >
    > Between the three different compilers I have available I see the
    > following difference in the object files:
    >
    > gfortran 4.2
    > 00000000 T __testmod__compute
    > 00000000 B __testmod__x
    >
    > Intel Fortran 9.1
    > 00000000 T testmod._
    > 00000002 T testmod_mp_compute_
    > 00000004 C testmod_mp_x_
    >
    > Sun studio 12
    > 00000000 T testmod.compute_
    > 00000000 B testmod.x_
    > 00000000 D testmod_
    >
    > Also the .mod file is different. <sarcasm>The new Fortran 2003
    > standard talks about C integration. How about to start with Fortran <-
    >> Fortran integration? </sarcasm>


    Ah - you think the language standard somehow dictates implementation details and/or standards?

    I don't even expect module files to be compatible across different versions of the *same*
    compiler from a particular vendor, let alone between compilers from different vendors.

    >
    > This means that you cannot compile a library with say gfortran and use
    > it in any other compiler.
    >
    > If you avoid using Fortran modules you can get something that is
    > binary compatible and usable between the three compilers I have
    > available and have also tested with. I have [1] a small example of how
    > to write "module code" without using modules. It boils down to using
    > INCLUDE instead. There are some negativisms with not using MODULES as
    > well but not as many.


    In my case, the makefile for you example would look the same whether or not I used modules
    or externals+include.

    cheers,

    paulv
    >
    >
    > Leading researchers is using Fortran 95 [2] with modules I guess I
    > just have to bend over and recognize that this is broken but nobody
    > but me seems to care about it. Also, if you look at the BLAS95
    > proposal routines, you see lot's of dangerous code. You see unsafe
    > EXTERN keywords. I would though out modules and replace it with type
    > checking any day of the week (Do not confuse modules with
    > interfaces.).
    >
    > I think Fortran 90 has lot's of nice features which I think is
    > essential to a modern programming language. I know I don't have to
    > follow everyone else and use MODULES. I don't even have to use Fortran
    > 90. But since so many are choosing to use modules and seems fine with
    > that - where did you dispose of the bodies of those who questioned it?
    >
    > Thanks for your comments. I would very very much like to hear what you
    > have to say about these things.
    >
    > [1] http://na37.nada.kth.se/mediawiki/in..._the_seventies
    > [2] http://www.cs.umd.edu/~stewart/matran/Matran.html
    >
    > Cheers,
    > --
    > Henrik Holst, Sweden
    > http://www.csc.kth.se/~holst/contact.shtml
    >



    --
    Paul van Delst Ride lots.
    CIMSS @ NOAA/NCEP/EMC Eddy Merckx

  7. Default Re: Fortran 90 modules suck for portability- why use them?


    "Greg Lindahl" <lindahl@pbm.com> wrote in message
    news:4697dfff$1@news.meer.net...
    > In article <4697D5A2.8050300@lrz.de>, Reinhold Bader <Bader@lrz.de>

    wrote:
    >
    > > C++ has the same issues here, although there
    > >may be more efforts to keep compatibility here

    >
    > Well, there are a lot of system libraries for C++, so for example on
    > Linux, gcc and Intel and PathScale all have the same mangling. You
    > can't have a viable compiler otherwise.
    >


    On Windows, however, there is less compatability. Watcom, Borland &
    Microsoft all used different schemes. Since the aim was to share a DLL, this
    was rather more upsetting than modules. And I believe this ocntinues -
    Microsoft & gcc still seem to use different approaches.

    > In the Fortran77 world, gfortran isn't even g77 compatible. So
    > PathsScale, which was g77 compatible for name mangling (but not the
    > I/O library), got burned when gfortran decided to mangle names
    > differently by default. Oh well.
    >


    Was it gfotran that did the name mangling, or gcc? I believe there were
    changes between gcc 3.x and 4.x. Since gfortran needs to be compatable with
    gcc, my immediate suspicion is that the fault lies with gcc, not gfortran.

    > And for the Fortran 9X world, well, there was obvious choice to
    > imitate.
    >
    > -- g
    >




  8. Default Re: Fortran 90 modules suck for portability- why use them?

    glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

    > Richard Maine wrote:
    > (snip)
    >
    > > All this has almost nothing to do with modules as a language design
    > > issue. Binary compatibility between different compilers, even on the
    > > same architecture, has always been a serious issue long before modules.
    > > In limitted circumstances, you can sometimes make it work, but the
    > > problems are great.

    >
    > I would have thought that the biggest cause of non-compatibility
    > was in argument passing.


    That's one, but I wouldn't call it the biggest. In practice, as far as I
    am aware, today you don't see a lot of different schemes on the same
    architecture. MS has their two different ones.

    I/O is a very big one. I'd suggest not even thinking about trying to
    open a unit number with one Fortran compiler and then reading/writing to
    it with another. I suppose there might be cases where it works... but
    you get better odds in Vegas. :-( The core of the problem is that I/O
    involves lots of support library stuff. The support libraries of
    different compilers aren't likely to play well together.

    --
    Richard Maine | Good judgement comes from experience;
    email: last name at domain . net | experience comes from bad judgement.
    domain: summertriangle | -- Mark Twain

  9. Default Re: Fortran 90 modules suck for portability- why use them?

    Richard Maine wrote:
    (snip)

    > All this has almost nothing to do with modules as a language design
    > issue. Binary compatibility between different compilers, even on the
    > same architecture, has always been a serious issue long before modules.
    > In limitted circumstances, you can sometimes make it work, but the
    > problems are great.


    I would have thought that the biggest cause of non-compatibility
    was in argument passing. There are now ever more efficient methods
    using registers in different ways.

    In the olden days, everything went on the stack (on machines that
    had a stack). For IA32 there was the caller pops/callee pops
    difference, but not so much past that. (For C, one had to pass
    pointers when calling Fortran, but that is a different question.)

    It would have been nice to standardize name mangling, though,
    so that if everything else worked the calls would work.

    Oh well.

    -- glen


  10. Default Re: Fortran 90 modules suck for portability- why use them?

    Richard Maine wrote:

    (snip)

    > I/O is a very big one. I'd suggest not even thinking about trying to
    > open a unit number with one Fortran compiler and then reading/writing to
    > it with another. I suppose there might be cases where it works... but
    > you get better odds in Vegas. :-( The core of the problem is that I/O
    > involves lots of support library stuff. The support libraries of
    > different compilers aren't likely to play well together.


    Yes, I/O tends to vary, but for the kinds of libraries that
    I think about there isn't much I/O. Error messages maybe,
    but that can usually be done by a return code instead of printing
    something.

    Otherwise, yes.

    -- glen


+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast

Similar Threads

  1. Taking a class that may suck?
    By Application Development in forum Javascript
    Replies: 27
    Last Post: 10-27-2007, 05:28 PM
  2. Why does the SBCL REPL suck so bad?
    By Application Development in forum lisp
    Replies: 32
    Last Post: 08-09-2007, 04:43 AM
  3. Does my JAPH suck?
    By Application Development in forum Perl
    Replies: 9
    Last Post: 07-14-2007, 02:30 PM
  4. Why does Eudora still suck so badly?
    By Application Development in forum Eudora
    Replies: 15
    Last Post: 05-22-2005, 02:03 AM
  5. Optoma Technology suck
    By Application Development in forum Hardware
    Replies: 0
    Last Post: 05-24-2004, 11:12 PM