Porting fortran from HP/UX to Linux

Let me start by saying I am NOT a fortran guy, and haven't used it in
probably 18 years, but I've been tasked with porting some old code from
an HP/UX system to Linux.  Can someone point me towards the most
compatible compiler that will require the least amount of rework to
recompile these apps?

Thanks a lot!
Tony

tivonut@gmail.com wrote:

> Let me start by saying I am NOT a fortran guy, and haven't used it in
> probably 18 years, but I've been tasked with porting some old code from
> an HP/UX system to Linux.  Can someone point me towards the most
> compatible compiler that will require the least amount of rework to
> recompile these apps?

This is too indefinite to give an answer.  Beginning about 10 years ago,
HP/UX Fortran lost a few of the peculiarities it had up to that time.
There was never a requirement to write non-standard code for HP/UX.  Is
your code from before the Fortran 77 era? Has it not been compiled in the
last 10 (30?) years?

You are in a better position than we to guess what strange problems may
exist in your code, but I can't think of any major differences between
compilers in their compatibility with HP/UX style.
--
Tim Prince

Tim Prince wrote:
>
> tivonut@gmail.com wrote:
> 
>
> This is too indefinite to give an answer.  Beginning about 10 years ago,
> HP/UX Fortran lost a few of the peculiarities it had up to that time.
> There was never a requirement to write non-standard code for HP/UX.  Is
> your code from before the Fortran 77 era? Has it not been compiled in the
> last 10 (30?) years?
>
> You are in a better position than we to guess what strange problems may
> exist in your code, but I can't think of any major differences between
> compilers in their compatibility with HP/UX style.
> --
> Tim Prince

A few caveats that I do remember from the days when we ported programs
_to_ HP/UX:
- By default the FORTRAN compiler would not decorate the
function/subroutine
names with anything, so we had several name clashes when combining
FORTRAN code and C code. You may see the reverse happen if you combine
these two languages.
- The HPUX FORTRAN compiler did not automatically save local variables
(that is, it used the stack or something similar to create local
variables). This could be changed however by a compiler flag. There
are several other compiler flags that may matter: one causes the
program to
use double precision reals, for instance, instead of single precision.

Such influences on the program outside the visible code may cause
problems.

Regards,

Arjen

In article <4291D0E3.1191D509@wldelft.nl>,
Arjen Markus <arjen.markus@wldelft.nl> wrote:

> A few caveats that I do remember from the days when we ported programs
> _to_ HP/UX:
> - By default the FORTRAN compiler would not decorate the
> function/subroutine
>   names with anything, so we had several name clashes when combining
>   FORTRAN code and C code. You may see the reverse happen if you combine
>   these two languages.

I ran into this one. It was a really big pain for me because it meant
that I had to change the documented API for my library. Making the code
changes was simple enough, but the fact that I then had to tell all of
my users to make corresponding changes in their code was painful.

It turns out that my API included procedures named things like fopen,
fclose, fread, and fs. Those names were chosen back when I still
needed to stick to 6-letter names for external procedures.  (Even after
I started accepting long variable names as an f77 extension, I stuck to
6-letter external names because of limitations on some systems). It is a
little hard to stick to 6 letters, make the names understandable, and
also avoid conflicts. I missed on the part about avoiding conflicts. The
names were also chosen before I knew much of anything about C or Unix...
obviously.

That experience left me with a good appreciation for the improved
namespace control afforded by f90 modules.  (I didn't say perfect, but
it sure is majorly improved).

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

Thanks for the quick replies.  As I understand it, it's Fortran 77
(they say the version is Fortran 9000 v.B10.0 if that means anything),
and began life about 15 years ago.  It was last compiled about 5 years
ago.  The box is currently running HP/UX 10.20.

Again, I know next to nothing about Fortran, more of a C guy.  When I
tried to recompile it under Linux, I got complaints about $ALIAS lines
(which I understand are compiler directives, similar to #DEFINE's in
C), and DATA <var> "/pathto/file" complaining about a type
disagreement.  So, before I delve into hand massaging each file, I
figured I'd first see if there was a better tool for this task than
g77.

Thanks again,
Tony

In article <1116866954.427647.23300@z14g2000cwz.googlegroups.com>,
tivonut@gmail.com wrote:

> I got complaints about $ALIAS lines
> (which I understand are compiler directives, similar to #DEFINE's in
> C),

I don't know enough about HP/UX-specific features to know exactly what
that would be.  My experience was more with porting to HP/UX than from
it. If it is something like #DEFINE, that can probably be ported
relatively simply in any of several ways (one of which is to make it a C
define and use cpp or one of its Fortran-aware variants).


> and DATA <var> "/pathto/file" complaining about a type
> disagreement.

That looks like one of the nonstandard Hollerith variants (using
character string syntax in Hollerith context). I presume that the <var>
here is a real or integer (or maybe double precision), and not a
character. If so, the g77 -fugly-init switch might help.

> So, before I delve into hand massaging each file, I
> figured I'd first see if there was a better tool for this task than
> g77.

If those are the only two problems, I suspect most any compiler will do
as well.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain

tivonut@gmail.com wrote:

> Again, I know next to nothing about Fortran, more of a C guy.  When I
> tried to recompile it under Linux, I got complaints about $ALIAS lines
> (which I understand are compiler directives, similar to #DEFINE's in
> C), and DATA <var> "/pathto/file" complaining about a type
> disagreement.  So, before I delve into hand massaging each file, I
> figured I'd first see if there was a better tool for this task than
> g77.

I did use HP/UX Fortran some years ago, and $ALIAS sounds slightly
familiar.   It might be that it is used when calling non-Fortran
(such as C) subroutines, especially if the names are not upper case,
or contain other characters that Fortran won't allow.

Posting some would make it easier to figure out.

-- glen

Richard E Maine wrote:
Those names were chosen back when I still
> needed to stick to 6-letter names for external procedures.  (Even after
> I started accepting long variable names as an f77 extension, I stuck to
> 6-letter external names because of limitations on some systems).

I still do.  Are there no systems still running where this is required
for portability?

In article <Cbrke.18955$8S5.8690@bignews3.bellsouth.net>,
Charles Russell <SPAMworFREEwor@bellsouth.net> wrote:

> Richard E Maine wrote:
>   Those names were chosen back when I still 
>
> I still do.  Are there no systems still running where this is required
> for portability?

I know of none. Of course, that doesn't mean that none exist.

And I suppose that it depends on your definition of "still running".

There are some pretty old systems that are museum pieces (literally) and
are still running. It has been a while since I booted up CPM on my old
Apple 2e, but I think all my hardware for it still works. If not, I
could certainly run it on one of the Apple 2e simulators that are
running around; after I finally get a Mac at home (currently
procrastinated for budget reasons), I will probably get a paid license
for one of them that I've briefly played with. It will be worth the
license (which is pretty cheap) just for the nostalgia value for me.

But if you mean "still being constructively used for new work" or, more
importantly for me, "that there is any chance at all of ever caring
about porting any of my new code to", then the answer is "no".

If you have a particular rare system that your stuff might need porting
to, you'd know more about that than I do.

Heck, for "modern" systems, long Fortran externals are the least of
people's worries. Some of the X-Windows and C++ names get downright
ludicrous. People XXXXX about Fortran's 31-character limit (in f90/f95)
as being too short, which is why it was bumped to 63 characters in f2003
(and I think some people were asking whether that was enough). And yes,
those are external names; that's why it was an issue for C interop.

--
Richard Maine                       |  Good judgment comes from experience;
email: my first.last at org.domain  |  experience comes from bad judgment.
org: nasa, domain: gov              |        -- Mark Twain