Our main evaluation criteria were:
1] The code produced had to be compatible with g77, f2c and gcc.
2] The compiler had to produce debugger symbols for the variables
inside common block. This is why ddd, xxgdb, etc. cannot directly
see the varibles in fortran common blocks. It is however possible
to get at the variable in g77 with a couple of tricks.
*] We did not consider improved optimization, as the numbers we
were hearing indicated at best 30% increase in speed.
One Caveat -- If the CERN Program Libraries were compiled using the
absoft compiler rather than the current f2c, most of
the product would probably be quite useable. We were
not interested in exploring this option due to the
large amount of work involved in building the CERN
libraries.
What we found:
*) If the CERN libraries were linked, they natuarally had to include
libf2c.a . However, due to some bizarre things with main_, MAIN_,
etc..., the images had to be lined with the "static" option. You
could not use the .so version of the library. This is not a
real limit, just an annoyance.
*) By default, the internal naming conventions of absoft common
blocks and g77/f2c common blocks differ. (Placement of underscores,
prepending C's, etc.). As such, even though the common blocks have
the same name in the code, the f2c/g77 and the absoft version map
to different memory -- THEY ARE NOT COMMON.
This can be fixed by compiling absoft using an option which forces
the common block convention to agree with that of g77/f2c. However,
this requires that ALL absoft code be compiled with this option.
In our mind this left too much room for problems. I.e. building
absoft libraries without the option, and then a lot of people
wasting a lot of time trying to figure out why code was crashing.
*) The absoft compiler does produce symbols for variables inside a
common block, but ONLY for those variables which are USED in that
particular subroutine. I.E. you cannot acces the variables which
are not referenced within the particular subroutine. (It is
impossible, unlike g77 where you can get at them if you try.)
While from this it is true that we could "tweak things" to work
with this compiler, there are enough trouble spots, that we
felt it might actually impeed software development, especially
since we are likely to maintain a mix of g77, gcc, fc2 and
absoft if we adopted this. Our conclusion is that we could not
afford this at the present state of the experiment. We are
therfore NOT planning to use absoft fortran at CMU on our LINUX
boxes.
Comments from others who have used absoft would be welcome --
curtis
---------------------------------------------------------------------------
! Curtis A. Meyer ! Snail: ! Email: !
! Wean Hall 8414 ! Dept. of Physics ! cmeyer@ernest.phys.cmu.edu !
! Tel: (412) 268-2745 ! Carnegie Mellon Univ! http://info.phys.cmu.edu/ !
! Fax: (412) 681-0648 ! Pittsburgh PA 15213 ! faculty/meyer/meyer.html !
---------------------------------------------------------------------------