willis@auvax.UUCP (Tony Willis) (11/29/87)
I would like to install a very large astronomical image processing
system on an HP9000 series 500 workstation. The image processing
system's code is largely written in F66 style and contains many
coding gems of the form
REAL TEST
DATA TEST/'ABCD'/
i.e. it uses the old F66 way of storing character data. Now most
Unix style f77 compilers tend to produce warning messages which tell me
that this coding style is hardly state-of-the-art, but they do keep
going and compile the code. (At least they do on a Sun 3 and a VAX 785
running Ultrix.) Unfortunately the HP9000 compiler produces a fatal
error message stating that the data types are incompatible and does
not complete the compilation. Therefore HP's compiler is clearly
not upwardly compatible with f66 code.
Now, this image processing system contains about 150,000 lines of code and
I don't intend to rewrite it in f77 style by myself. So my question is -
has anybody else encountered this problem and if so, can it be
solved without rewriting the code? Is any kind of work-around solution
available from HP?
Tony Willis
Athabasca University ...{ubc-vision,ihnp4}!alberta!auvax!willis uucp
Box 10,000 usercdir@ualtamts BITNET
Athabasca, Alberta TOG 2R0
Canada (403) 675-6221 gil@icus.UUCP (Gil Kloepfer Jr.) (11/30/87)
In article <429@auvax.UUCP> willis@auvax.UUCP (Tony Willis) writes: >I would like to install a very large astronomical image processing >system on an HP9000 series 500 workstation. The image processing >system's code is largely written in F66 style and contains many >coding gems of the form > REAL TEST > DATA TEST/'ABCD'/ >i.e. it uses the old F66 way of storing character data. Now most >Unix style f77 compilers tend to produce warning messages which tell me >that this coding style is hardly state-of-the-art, but they do keep >going and compile the code. (At least they do on a Sun 3 and a VAX 785 >running Ultrix.) Unfortunately the HP9000 compiler produces a fatal >error message stating that the data types are incompatible and does >not complete the compilation. Therefore HP's compiler is clearly >not upwardly compatible with f66 code. > >Now, this image processing system contains about 150,000 lines of code and >I don't intend to rewrite it in f77 style by myself. So my question is - >has anybody else encountered this problem and if so, can it be >solved without rewriting the code? Is any kind of work-around solution >available from HP? Although I am not familiar with HP FORTRAN, I would think that you could probably search-out the declarations of string variables (with your editor) and find a list of variables which this problem happens in (look for lines with an apostrophe in it). Change these to CHARACTER*4 (see below) and then compile (and get 100,000 more errors where you get a character variable being assigned to a REAL). A few passes this way should eventually (but painfully) solve the problem. I'm sure this is not a sound solution (so no flames on this) .. but its the only one I could think of. **NOTE** Even more importantly -- does anyone KNOW what a REAL is defined as in FORTRAN. It occurred to me that, depending on the machine in question, a REAL could be 2, 4, or 8 bytes long, limiting the number of characters which may be stored in a REAL. I am unaware of any clear definition in the F66 standard (anyone else know?). I know this doesn't answer the above question sufficiently, if at all. I thought it may be interesting to raise a few questions about this practice in general. I'm sure there's more than just one 150,000 line program written line this. Someone is probably stooped over a terminal right now trying to make one of these dogs work! Someone's answer to my question may help too. ------------------------------------------------------------------------------ Gil Kloepfer, Jr. USENET: ...icus!gil ICUS Computer Group, Systems Development P.O. Box 1 Islip Terrace, New York 11752 ------------------------------------------------------------------------------
shankar@hpclscu.HP.COM (Shankar Unni) (12/03/87)
Talk to the HP response center people. They ran into a similar problem with a *very* important customer (who shall remain nameless), who had literally millions of lines of FORTRAN66 code. The answer was to come up with a tool for migrating HP FORTRAN 66 to HP FORTRAN 77. The catch: This is for the new series 800 machines; however, it should work pretty well on the s500, too. Shankar Unni ...!hpda!shankar
chuck@hpunsca.UUCP (12/03/87)
>I would like to install a very large astronomical image processing >system on an HP9000 series 500 workstation. The image processing >system's code is largely written in F66 style and contains many >coding gems of the form > REAL TEST > DATA TEST/'ABCD'/ >i.e. it uses the old F66 way of storing character data. Now most >Unix style f77 compilers tend to produce warning messages which tell me >that this coding style is hardly state-of-the-art, but they do keep >going and compile the code. (At least they do on a Sun 3 and a VAX 785 >running Ultrix.) Unfortunately the HP9000 compiler produces a fatal >error message stating that the data types are incompatible and does >not complete the compilation. Therefore HP's compiler is clearly >not upwardly compatible with f66 code. ---------- Well, I could be shot on sight by *good* programmers, but here's a solution which will do the trick (I tried it with my Rev5.11 s500 compiler) - REAL TEST DATA TEST/4hABCD/ ! Simply edit this statement This is not great, but it works, and eliminates most of the headaches which occur when those REALs get equated to some other data type (which probably happens in code of this vintage, along with GOTOs, etc.). You should be able to search for all occurrances of this with your editor. Hope this helps. Chuck (*not* a great programmer) Munro.
cdb@hpclcdb.UUCP (12/04/87)
In addition to Shankar's advice about contacting the Response Center, I also posted the following in comp.lang.fortran : Unfortunately, the Fortran 66 standard was too weak to really standardize very much. Fortran 77 added the CHARACTER data type to handle these kind of problems. Actually, the official Fortran 66 standard did not allow quoted character strings. It had Hollerith constants, but even they were only allowed "in the argument list of a CALL statement and in the data initialization statement" (ANSI X3.9-1966, p.10). At least that shows a way around your problem - you could roll it back to real F66, by converting the quoted strings to Hollerith (at least in DATA statements). The previous response (at least on my machine) suggested moving such things forward to F77, using CHARACTER variables to hold character data. Strange idea, very un-Fortranlike! :-) You might note that Hollerith constants were removed by the 77 standard, and are unlikely to reappear in the standard (though most implementations will continue to have them). In practice, I'd do whichever looked easiest. Carl Burch hplabs!hpda!cdb
wcs@ho95e.ATT.COM (Bill.Stewart) (12/13/87)
:>I would like to install a very large astronomical image processing
:>system on an HP9000 series 500 workstation. The image processing
:>system's code is largely written in F66 style and contains many
:>coding gems of the form
:> REAL TEST
:> DATA TEST/'ABCD'/
:>i.e. it uses the old F66 way of storing character data. [...........]
:> Therefore HP's compiler is clearly not upwardly compatible with f66 code.
No, you're wrong there. The problem is that the code you're
working with is incompatible with the Fortran 66 standard; it's
something that probably worked on an IBM 360/370. Since F66
doesn't support character data types, Hollerith data could be
stored in integers, normally INT*4 holding 4 characters, since
this is what works best on an IBM. Even that was non-portable (if
you moved binary data to a machine with a different byte order,
it might get scrambled.) If you use REAL, you're much more likely
to lose (does REAL default to REAL*4 or REAL*8? IEEE? Are REALs
handled by the CPU or a separate Floating Point Unit?)
One of my co-workers is translating some code that ran on a
Harris machine with 24-bit integers, and the orginal authors
took advantage(?) of the benefits (?) of packing 3 characters
to an INT*3. You're lucky it's at least REAL*4.
In article <370006@hpunsca.HP.COM> chuck@hpunsca.HP.COM (Chuck Munro) writes:
: REAL TEST
: DATA TEST/4hABCD/ ! Simply edit this statement
If you're lucky, this will work. Just don't do anything that assumes
anything special about the order the bytes are stored in (e.g. if TEST2
contains 4hEFGH, don't assume the D and E are adjacent, and don't use
any EQUIVALENCE statements is you care which bytes are first.)
--
# Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs