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 ------------------------------------------------------------------------------
cdb@hpclcdb.UUCP (12/04/87)
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