Program EZUP provides startup help in converting FORTRAN77
source codes to forms more suitable for use with Lahey's
Essential Lahey Fortran 90 (ELF90) - or some other fortran 90
compiler. EZUP makes only some of the conversions and leaves
the hard stuff to you. EZUP may also destroy the appearance of
your code because the output file will not be "free form",
and will look somewhat stiltedly like old-fashioned FORTRAN
(rather than New fashioned fortran). The input files must
also conform to old-fashioned column usage rules.
(ELF90 is a "moving target" in that some statements accepted in version
1.0 are not valid in later versions. No attempt is being made to
keep EZUP "in sync" with later ELF90 versions.)
The current version number is 2.00 (9 Dec 1998) - Windows 95/NT ONLY!
(See the file EZUP.TXT in EZUP.ZIP for info on changes between versions)
***************************************************************
** VERY IMPORTANT NOTICE TO USERS OF PRIOR VERSIONS OF EZUP **
***************************************************************
* VERSION 1.14 HANDLES "CONTINUE" STATEMENTS WHICH TERMINATE *
* "DO LOOPS" QUITE DIFFERENTLY THAN ALL PRIOR VERSIONS! *
* *
* Refer to paragraph "f" (below) for further information *
***************************************************************
DISCLAIMER: ALL THE USUAL FREEWARE DISCLAIMERS APPLY
USE THIS PROGRAM AT YOUR OWN RISK!
THE AUTHOR DISCLAIMS ANY LIABILITY FOR ANYTHING!
COPYING: EZUP is the "intellectual property" of August Miller.
A license to employ it for non-commercial use is
hereby granted to any individual who wishes to do
so. Usage of the program is understood to imply
acceptance of the above disclaimers and any others
which might reasonably apply to "freeware".
However, the fact that you may use it in a
non-commercial environment does not mean that you
are free to use it for any other purpose without
express written permission of the author. In fact,
you CANNOT legally do so.
All that not withstanding, permission IS granted to
place UNALTERED copies of the EZUP.ZIP archive
(but not individual files found therein) in BBS
or internet accessible archives so long as no
specific fee is charged for downloading a copy.
You cannot sell or resell it for profit without the
above mentioned written permission.
----------------------------------------------------------------------
Some rules about the input files:
1) Source code must be more or less standard F77 (or earlier) in
form, and may not contain ANY blank lines.
2) Maximum number of do-levels is 20
3) Maximum number of labels in a program unit is 400, and the maximum
number in a single instruction (including continuation cards) is
20.
4) Apostrophes may give trouble in some cases, such as
IF (TMP(1).EQ.'Y') GO TO 400
(but they may turn out ok, too).
5) Continuation card limit is ABOUT 20.
6) EZUP quits after 9999 lines (in a program unit, not the file
(but it hasn't been tested on anything longer than about 3800
lines).
7) EZUP may choke on unlabeled DO loops, i.e. DO I=1,5 ... END DO,
but versions 1.10+ try to avoid that.
---------------------------------------------------------------------
About the Output files:
1) Sequence numbers in postions 73-80 will be lost.
2) Output is "old" FORTRAN formatted (although an occasional
character or two may be pushed past column 72):
a) Statement labels are in columns 1-5.
b) Continuation lines all carry the & in column 6 and are
broken for continuation at column 71 (with & in col. 72);
unindented statements begin in column 7.
c) DO-LOOPS and IF-THEN-ELSE blocks may be indented.
d) All C's in the first column are replaced by exclamation marks.
e) Numeric labels are removed from DO nnnnn statememts, and an
"end do" statement is inserted to terminate each do-loop.
(Unhappily, there will be 5 or 5 space codes in place of the
deleted numerals.)
f) Do-loops terminating on nnnnn CONTINUE are rewritten as
nnnnn MYCDEF=0
Remark: The statements which terminate do-loops are retained
in the above dummy form because the CONTINUE might be the target
of a "GO TO". EZUP tries to put the "nnnnn MYCDEF=0" statement
just "INSIDE" the appropriate "END DO".
****************************************************************
* THE POSITIONING OF THE REPLACEMENT STATEMENT IS DRAMATICALLY *
* DIFFERENT THAN WITH EZUP PRIOR TO VERSION 1.14 !! *
*************************************************************
Exception: If the label nnnnn is never referenced (except in the
"DO nnnn ... statement, then the whole line will be deleted.
g) Other NNNNN CONTINUE statements become
KKKKK IJKLMN=1
Exception: If the label KKKKK is never referenced, the whole
line will be deleted.
h) ENDIF is expanded to END IF, and ELSEIF is expanded to ELSE IF
i) GOTO is expanded to GO TO
j) ALL statement labels are RENUMBERED consecutively, except that
the renumbering is done before deleting unreferenced labels.
So, some of the "new" labels will be missing, thereby fouling
the just claimed consecutive feature. But, at least they will
all ascenting numbers (in order of appearance).
k) "IMPLICIT NONE" is inserted immediately after the first line
in each routine, and the line
INTEGER :: IJLKMN, MYCDEF
is inserted to define the variables added under items (h) and
(g) above.
Any existing IMPLICIT statements are deleted.
l) Things like:
IF(X-XMAX)10,10,30
10 IF(X-XMIN)30,20,20
20 XRANG=0.0
30 RETURN
and
GO TO (10,20,30,40,50), IVAR
are relabeled but no other changes are made..you must tackle
them yourself if modification is needed.
m) Most characters will be converted to upper case (except in
comments and formats).
n) A modest attempt is made to collect a list of variable names
which appear immediately on the left of "=" signs.The list may
be useful for assigning data types as required with the "implicit
none" situation. Only strings of 6 or fewer characters are
considered legal names, and the identification scheme WILL
MISS ARRAY NAMES (as in VICTIM(J,K)=aval). The scheme may also
fail to skip over things like RECL in statements like
Open(lunin,FILE='somefile', RECL=127,....). Nor are any
cheks made to prevent the same string from appearing more
than once. The source code was programmed to handle a maximum
of 600 strings in a program unit.
The list is appended to the end of the actual code and is
delimited by the exclamation mark in column/position no. 1.
o) General data typing effects (bugs and features)
REAL ABC, AVAR becomes:
REAL(4) :: ABC,AVAR
REAL*8 ABC, AVAR or DOUBLE PRECISION ABC, AVAR becomes:
REAL(4) :: ABC,AVAR
REAL ABC, IVAR becomes: REAL(4) :: ABC
INTEGER :: IVAR
COMPLEX Z1,ZZ,Z3 becomes:
COMPLEX(4) :: Z1,Z2,Z3
COMPLEX*8 Z1,Z2,Z3,Z4 becomes
COMPLEX(4) :: Z1,Z2,Z3,Z4
COMPLEX*16 Z1,Z2,Z3,Z4 becomes
COMPLEX(8) :: Z1,Z2,Z3,Z4
CHARACTER A,B,C becomes
CHARACTER(LEN=1) :: A,B,C
CHARACTER*32 ANAME, BNAME(10) becomes
CHARACTER(LEN=32) :: ANAME, BNAME(10)
CHARACTER ANAME*32, BNAME*64 becomes:
CHARACTER(LEN=32) :: ANAME
CHARACTER(LEN=64) :: BNAME
CHARACTER*(*) STRING(*) becomes
CHARACTER(LEN=*) :: STRING(*)
(I dunno whether that is right or wrong!)
DIMENSION A(12,34), MYARRY(20,200) becomes:
REAL(4) :: A(12,34)
INTEGER :: MYARRY(20,200)
****************************************************************
** NOTE ASSUMED DATA TYPES ARE FROM OLD-STYLE ("IMPLICIT ALL")**
** (A-H,0-Z) ARE REALS AND (I-N) ARE INTEGERS SCHEME. **
****************************************************************
LOGICAL ISTRUE, ISNOT becomes:
LOGICAL :: ISTRUE, ISNOT
p) At the end of each program unit, the output file will contain
a list of "apparent" variables. Unless the original code used
the IMPLICIT NONE statement, you will probably need to
create explicit data type definition statements for the
variables found in this list. Doing that is a bit of a pain,
but that may be the part of being frugal and not buying
fancier compilers and conversion software.
The variable name recognition scheme is primitive and looks
only for strings like " AONE=28.4E-16", from which it
assumes that AONE represents a variable of unknown type.
The scheme might also think that "READ(8,23,ERR=300)" means
that ERR is also a variable. That usually will be detected,
but MIGHT get through to the final list.
The biggest failure of the scheme is the failure to recognize
that ABCD(I,J)=.... makes ABCD a variable which will require
a type declaration. That will probably not be necessary, however
if there was a statement like DIMENSION ABCD(23,19) in the
declarations portion of the code....
q) You will also see a (commented) list which shows which of
the renumbered statement labels were deleted (sometimes
the lines which contained them as well!). The relabeled
code as it appeared before checking for unreferenced labels
may (sometimes) be found in the file REVISED.TMP. In order
to make this file accesible, it is NOT deleted automatically
at the end of EZUP execution. However, it IS overwritten
by each new program unit. So, if you want to see what labels
and or lines were deleted in a particular routine, you will
need to run it through EZUP on a "standalone" basis (a file
of its own).
o) When EZUP knows that it cannot convert a particular statement,
warnings will be displayed on the console and a commented
similar statement will be placed in the output file.
p) See the appendix below for information regarding COMMON BLOCK
processing.
q) EZUP Version 1.13 produces an additional output file aimed at
assisting in the construction of INTERFACE blocks for sub-
routines and functions found within an old source file. Output
file INTRFACE.OUT will contain the "guts" of the information
needed for that purpose. Users must do a bit of manual editing
to copy the appropriate portions of that file into the proper
location of their actual program code, and (more work!) perhaps
to adjust the INTENT statements to reflect proper IN, OUT or
INOUT attributes for parameters.
There are, however, SOME types of program units (BLOCK DATA, for
example) for which meaningless INTERFACE blocks are created. Users
will just have to deal with those on their own. Since such meaning-
less INTERFACE blocks are not automatically inserted into output
program code, they should not cause serious problems.
Another undesirable quirk is that a SUBROUTINE involving no "passed
arguments" will show up in toto in the INTRFACE.OUT file. Just
ignore it (if you can).
PLEASE NOTE that the file INTRFACE.OUT is overwritten each time
EZUP is executed, so if you want to keep the data belonging to
one source file, be sure to rename INTRFACE.OUT before executing
EZUP again!
r) EZUP also makes a modest attempt at trying to convert oldfashioned
common blocks to modules. Results apply only to a single source
code file and there are a number of limitations (some removable,
some not) as described elsewhere.
EZUP scans a source file (whose name you enter via keyboard) and
attempts to locate all common blocks and declared variables. It
constructs a partly converted source file, plus a special file
named MODULES.OUT. Initially all variables found in the modules
are declared to be of data-type UNKNOWN. The source file is then
re-examined and attempts are made to replace the UNKNOWN with a
more appropriate data-type if type declarations can be found.
The process surely is not fool proof and some interactive editing
will be required before you can convert MODULES.OUT to a really
legal " .F90 " file.
*****************************************************************
* *
* BECAUSE THE MODULES.OUT FILE IS OVERWRITTEN EACH TIME EZUP IS *
* IS EXECUTED IT IS VERY IMPORTANT THAT YOU RENAME THE *
* MODULES.OUT FILE TO SOMETHING ELSE BEFORE RE-EXECUTING EZUP *
* WITH A DIFFERENT SOURCE FILE. THE SAME IS TRUE OF THE FILE *
* NAMED INTRFACE.OUT. *
* *
*****************************************************************
More details and GOTCHA's:
1) All variable and common block names are truncated to 6 characters.
2) Only ONE "blank" common block is allowed and it is always
converted to MODULE DEFALT.
3) No checks are made to see that common blocks are of consistent
size when declared in different program units.
4) Only the first declaration of a common block is processed.
5) An attempt is made to identify data-types for the variable names
placed in the MODULES.OUT. The data-type used will be he first
one found in the source file associated with each variable name.
All detected common block variables which cannot be associated
with a data-type assigned to a variable with the same name
SOMEWHERE in the source file are given the default data type
"UNKNOWN". That is a variable named A3 will be declared in the
MODULES.OUT file as "UNKNOWN :: xxxxxx" , where xxxxxx is the
symbolic name of the variable. YOU must deal with those yourself.
NOTE WELL: There are some pitfalls in trying to associate variable
names found in common block declarations with the data-type of
variables names found in the source code. In particular, EZUP
does not guarantee that the pair of names will come from the
SAME PROGRAM UNIT, although it tries to impose that obvious
requirement.
For example, suppose that variables IX, IY and IZ AX appear
in a statement of the form "COMMON /TRASH/ IX,IY,IZ" somewhere
in the FIRST program unit in the source file, AND there is no
corresponding data type assignment (expecting them to be
treates implicitly as INTEGER).
Now suppose that some OTHER program unit of the source file
(perhaps a subroutine) contains a variable declaration
"REAL*4 IX,IY,IZ", but that the statement "COMMON /TRASH/ IX,IY,IZ"
does NOT appear in that program unit.
BAD MEDICINE! EZUP *MIGHT* assign the REAL(4) type to IX,IY and
IZ in MODULE TRASH derived from the first appearance common
block "TRASH"!
MORAL: BE CAREFUL!
6) Another of EZUP's (many) shortcomings is its inability to REMOVE
type declaration statements from the main source code when (if!)
it duplicates them in the new MODULES.OUT file. That will likely
give a collection of compilation errors arising from multiple type
declarations for each variable in a module.
That might be a blessing in disguise, however, because it might
warn you about possible "gotcha's" of type 5 (above). But, DON'T
bet you job on it.
--------------------------------------------------------------------
Things EZUP is definitely incapable of doing:
1) converting FORMAT statements containing banned items such as
10X,1P,E10.3.
2) doing anything at all with EQUIVALENCE statements.
3) replacing BLOCK DATA routines.
4) converting PRINT * and READ * statements.
Another thing:
5) CHARACTER statements may sometimes particularly convoluted in ways
I have never imagined (or merely am too ignorant to comprehend) and
may very well be converted to something worse than they were. Send
along your pet-peeves.
--------------------------------------------------------------------
How to use it:
Run EZUP from a command prompt (or Win 95) as you would any
other non-windows program.
You will need to enter a numerical value (say 10) to be used
as the new value for the lowest numbered statement label, and
a value (say 10 again) for the increment between label values.
Then a name for the input file, and a name for the output
file. I think that path names are legal but only up to 32
characters.
If all works properly, you will be warned if you choose the
name of an existing file as the name of the output file.
Two temporary files (TEMPCOPY.FOR and REVISED.TMP) are created.
You may want to delete them if they are not deleted automatically
but it is not necessary to do so.
You may occasionally see incomprehensible error messages.
Do not expect the author to explain what they mean. He has
probably forgotten.
The final output file will most surely NOT error or warning free,
but it should be in a form which will save you a lot of grubby
character by character editing which would otherwise be needed.
----------------------------------------------------------------------
OTHER:
Files:
EZUPnnnB.EXE: 32 bit Windows 95/ Windows NT executable
EZUPnnnL.EXE: 32 bit Lahey LF90v3 + TNT-extended DOS excecutable
ATEST.FOR: Test file to check various operations; not
a compilable FORTRAN program.
ATEST.OUT: Result of EZUP on ATEST.FOR
MODULES.OUT: Sample MOUDULES.OUT file based on ATEST.FOR.
INTRFACE.OUT: Sample INTRFACE.OUT file based on ATEST.FOR.
EZUP.TXT: This file
Constructive comments will be appreciated. If you have any
of those, please direct them to internet address: amiller@REMOVETHECAPSphysics.nmsu.edu
or w5ygr@REMOVETHECAPSjuno.com
I hope that the program is useful to someone other than me, and I
would like to hear from you if you find that it is.
August Miller
Occasional telephone: (505) 646-3428
----------------------------------------------------------------------
KNOWN BUGS AND PROBLEMS OF WHICH YOU SHOULD BE AWARE
Because EZUP takes some shortcuts in attempting to determine statement
types, labels and so forth, it is possible that certain kinds of statements
will be misinterpreted and cause disastrous behavior of EZUP (it might
even fill up your disk if you redirect console output to a file!). The
problem is that when EZUP sees certain "phrases" it may assume that
other things POSITIVELY, ABSOLUTELY MUST appear on the line. If they do not,
then EZUP may find itself looking thorough the proverbial completely dark
room seeking a black hat that is not there.
For example, the statement
GWORD='GOTO'
causes EZUP to assume that it is dealing with a standard "GO TO" statement.
If it IS, then there MUST be a "label" somewhere to the right of the second
letter "O". But it looks in vain, and may possible conclude that the ASCII
representation of the label is " ", that is, five consecutive SPACE-
codes. When EZUP later tries to match that target label with a list of
statement labels found in columns 1 through 5, EZUP comes up quite confused!
In such a situation, EZUP's may issue a seemingly endless stream of error
messages from subroutine SCRP. If you encounter such a state of affairs
ossible causes (but not the only ones) may be the presence of statements
such as:
GWORD='GOTO'
KALL='CALL'
ERRB=',ERR='
ENDB=',END='
READB='READ('
WRITB='WRITE'
DLP='DO'
NDCARD=' END'
all of which are found in EZUP itself. The only way I have so far found to
avoid trouble is to:
1) put a "C" in column 1 in the offending lines of the source code.
2) run EZUP
3) edit the output file to remove the !-symbols inserted in place of the C
in column 1.
4) (perhaps) inserting type-declarations manually.
*************************************************************************
CAVEAT EMPTOR
AS ALWAYS, YOU USE EZUP AT YOUR OWN RISK!
*************************************************************************
If your old programs are even moderately complicated,
try to scrape up the money to buy a REAL (no pun!)
F90 compiler and forget about trying to convert your
old codes just to make use of a free compiler!
---------------------------------------------------------------------------
MISCELLANEOUS TOPICS
TEMPORARY files created by EZUP are:
TEMPCOPY.FOR
INTRFACE.TMP
TEMPSUBR.TMP
REVISED.TMP
SCRATCH1.TMP
SCRATCH2.TMP
OUTPUT files are:
MODULES.OUT (may not be present if fewer than 3 lines long)
INTRFACE.OUT (may be irrelevant or empty in many cases)
YOURFILE.xxx (file name YOU chose for the outfile)
--------------------------------------------------------------------------
Click
here to download the latest version of ezup.