Trailing-Edge
-
PDP-10 Archives
-
tops10and20_integ_tools_v9_3-aug-86
-
tools/casestdy/case4.mem
There are 3 other files named case4.mem in the archive. Click here to see a list.
DEC20/VAX CONVERSION ITEMS
1. Accuracy
2. Character data
3. Logical bit manipulation
4. Open statement
5. Random number generator
DEC20/IBM CONVERSION ITEMS
1. Accuracy
2. Character data
3. Logical bit manipulation
4. Open statement
5. Random number generator
6. ASCII/EBCDIC conversion ("tab" char. problem)
7. Free-field formatting
8. Hexidecimal constants
9. Carriage control
10. Comments
11. Encode/Decode
12. Format literals
13. "Tab" in col. 1
1
"MONTE CARLO" FORTRAN PROGRAM CONVERSION
This is a list of the Fortran conversion items
encountered during the Monte Carlo program conversion.
The items are rated in severity of impact on a
conversion, with 5 being the most severe, down to 0 (for
probably no effect). In addition, for the two fortran
classes, an estimate has been made of the percentage of
existing Fortran programs that are affected.
-------------------------------------------------------------------------
FORTRAN CONVERSION TASKS EFFORT INVOLVED FREQ. OF MONTE CARLO CONVERSION DEC20--VAX DEC20--IBM
OCCURANCE
-------------------------------------------------------------------------
Accuracy (36 bit to 32 bit) 5* 5* 100
5 char/word to 4 char/word 4 4 100
Logical bit manipulation 4 4 10
Free field formatting 2 4 80
Random Number Generation 1 1 5
Character mode (ASCII to EBCDIC) 0 2 25
("tab" char. problem)
Hex and octal constants 1 2 25
Cursor/screen control 0 5 50
File specifications in OPEN st. 1 1 95
Instruction line comments 0 1 20
ENCODE/DECODE 0 1 60
Continued literal in format st. 0 1 10
"tab" in col. 1 of statement 0 1 100
---------------------------------------------------------------------------
2
Verifying and accepting changes in output accuracy due
to the different word length would be a length task in any
event. IN ADDITION to this, there are programs (such as EPA
certification) for which the results obtained from the new
system must EXACTLY match the previous results. These
programs will be a special problem; a 32 bit fullword will
give minor (but in this case important) differences in
computational accuracy, and even changing to double
precision may not eliminate this. (Double precision will
hold MORE accuracy than the original 36 bit word, and this
would STILL introduce differences into the converted program
output.
3
The following have been identifi major conversion
considerations. This list c conversion considerations;
issues such as computer po res time, and f
applications development have not been included.
-----------------------------------------------------------------
Description Effort Involved Freq. of
DEC20 to DEC20 to Occurance
VAX IBM
-----------------------------------------------------------------
FORTRAN CONVERSION AREAS:
------- ---------- -----
1. Synamic filename specification 0 5* 25
2. Data Base handling 1 4 85
3. Graphics ? ? 20
4. Cursor control 2 ? ?
5. Baseline Fortran program 2** 3** 15
(not using 1-4) -- conversion
of the Monte Carlo program
** overall "average" of time and
effort spend on Monte Carlo
conversion.
OTHER AREAS:
----- -----
1. System level command files 2 4 100
2. Batch control files 2 4 100
3. Data base control files 1 5 100
4. Rebuild data bases 1 3 100
5. Rebuild screen interfaces 1 5** 100
6. Special software (Versatec, ? ? 100
Zeta, Nyplan, Plot79, PacII)
-- Availability
-- Data conversion
7. MACRO 5 5 100
8. BASIC 2 3 100
* Indicates that no comparable facility exists. Conversion
would require extensive recoding or multiple custom
coding to simuate this capability.
4
EFFORT SCALE FOR FORTRAN CONVERSION
0 --- No conversion necessary.
1 ---- can be performed by a search/replace without any
additional checking.
2 ----- changes that must be checked with a global search to
confirm that the change will no cause problems.
Single statement changes that require completely
reworking a statement.
Changes that require fixed data format changes.
3 ----- Changes that require tracing parameter(s) values
through the program.
Changes that require SLIGHT learning of meaning of
existing code.
4 ----- Changes require replacing groups of statements where
the new group is a simple replacement of the old one.
Variable data format changes.
Changes requiring SOME learning of meaning of
existing code.
5 ----- Major changes:
Those requiring EXTENSIVE learning of meaning of
original code.
Accuracy verification. This is a major conversion,
even though it is not a code "change."
NOTE: This scale reflects both the difficulty and the time
neces to a s change of the ty described. Howe multiple occurrences of a change inc for that change
repl every tab in 1 with the co nu of spaces). On this conver there w several "simple" changes of this type too appreciable time to make.
5
EFFORT SCALE FOR "OTHER AREAS"
1 ----- No conversion necessary
2 ----- changes that can be made without checking for upstream
or downstream considerations of effects.
2 ----- changes that require "routine" checking (such as a
global search) to insure there are no prior or
subsequent effects.
Changes that require rewriting old code, but on a
line-for-line replacement basis that would not require
knowledge of the meaning of the old code.
3 ----- changes that would require tracing parameters or
control parameter values through a control file to
insure correct operation.
cha would require SLIGHT lea of meaning
of existing code.
4 ----- Changes requiring replacing groups of statements
where th group is a simple replac of the old
one, but without a no-to one correspondence between
individual lines. The converted code retains the
"structure" of the old code.
Changes requiring SOME learning of meaning of
existing code.
5 ----- Changes requiring extensive rewriting of code resulting
in new code that is structurally different from the old
Changes requiring EXTENSIVE learning of the meaning
of the old code.
6
"MONTE CARLO" FORTRAN PROGRAM CONVERSION
DEC20/VAX & DEC20/IBM COMPARISON
Monte Carlo program was converted fro 20 to
both the VAX 75 the IBM 4331/VM to obtain an estimate o
ef needed to convert a "benchmark" progra a differ
system. Having the same pr conv to both the VAX and
IBM also provided some data about the time difference be the
two conversions.
need convert the DEC20 program to the IBM 4331
was about 1./3 to 1.4 times that needed to convert to the VAX.
Two important mus about this estimate.
Fi ther no vital cursor or screen control/forma
the Carlo pro therefor question of terminal typ con not figur eff Sec two
conversions were not ma a to separate basis first
conve DEc20 program to the VAX; the req
later to co it DEC20 to IBM. I rea of had been done on the DEC20/VAX conversion was necessary
for the DEC20/IBM conversion (in particular, the shift from a 36 ful byte-oriented 32 bit fullword). I therefore
started the IBM conver usin converted pr
in of starting again o DEC20 ver and kept
any "VAX dependent : work that had to be undone to the IBm
version. As it turned out, there was very little that had to be
undone.
This "consecutive" effort was reflected in the t
esti two conversions. The VAX conve time
included only the time n for the VAX ch to the code.
Th conversion inc the VAX conversion time AND need convert the VAX version to the IBM.
DEC 20 to VAX CONVERSION
The biggest e in this conve shi
"alphanumeric" variables and arrays from a 5-character/word configur 4 characters/word (byte oriented 32 bit
fullword) use by the VAX. Shifting some parameters from
single preci to d prec of part of the
problem, but many arrays had to be redimensioned to kee
allowable s length. Similarly, format editing paramet
had to be redone to match the shifted arrays.
Two programming techniques that had been us
original pr required over For
"character" data was ca in both real and in variables
( no way of handling it). The VAX For 77,
which includes th character/string manipulation features,
severely restr the manipulation and output of character data in a rea
in vari Solving this rewr lines (and at sect
code
7
The second programming technique that required restructuring
was lo bit manipulati an assignment state the
DEC20, the assig stat A=B.OR.C is legal with logical,
int parameters. On the howe
parameters are not allow Furtherm crea inte
parameters set equal t need operation
would not work; the conversion in executing the instruction would
destroy the original bit pat Backup and reworking code to
onl allo types whe logical assig
statements were executed had to be done.
A format fe figured i conversion even
thoug was not troubl AT THIS T DEC20 Fo
free f and "I" format exa for
stat FORMAT(7F) will allow the correct edi of up to
seven real quant located anywhe the record, as long as
there i leas space between adjacent fields. The VAX
Fortran does not formally support this free capabilit
even me it, so far as I could find). While experimenting
found tha field formatting would work o VAX if the
f were seperate by commas instead of (o addi to)
spa Therefore, with the changed data syntax, the free field
forma still functio VAX Fortran, but since
formally supported, DEC has no obligati pre
future editions of VAX Fortran.
Other ch were necessary, but were "normal"
conver items, such as different r number generator
syntax and different OPEN statement syntax.
DEC20 to IBM 4331/VM CONVERSION
As I noted be I started this conversion with the VAX
c rather than the DEC20 code. The only VAX fe had
to be "b was the new OPEN statement sy the changes
neede DEC20/VAX shift were entirely replace
needed IBM changes. This was the only identifiable "lost" eff
from the VAX converted code.
Mo the source cod files over to the 4331
converting them to EBCDI a major proble did not include
this as part of my Fortran conver how even a
smoothly-running transfer from one ma to another would need
some time per program to be performed. i could not est
at this time.
Se conversion items were found changing the to IBM. The foremost of these was that free-field "I" and
"F" ed is not supported, either for or inform To
convert the code, all I/O using this featur shifted to list-
directed I/O, a now-standard fortran feature. The only way to
make this work w a fu chan entry
syntax; in additio the comma-separation use
version, any "character" f on the data input r
enclosed in qu the record mu terminated by a
"/"/.
8
Ano far less major, conversion item was specifying
a hexadec cons in an assignment statem Thi
al DEC2 VAX Fortran, but not on IBM VS For
Fortran allows hex constants only dat parameter
statem I conve the progr specifying e hex
constant used in the program in DATA statement.
Se other "normal" conversion were found
converted. One that was found that could not be converted was
specif a fi "readonly" in the Fortran source c On 4331, this could only be done in the FILEDEF or JCL, and not
at the source level.
COMPARISON OF CONVERSION EFFORTS.
During th conversion eff I kept track of the time
actually sp included actual code convers research learning, and dead ends. After each conversion, I also
estim the time that be necessary to convert a si
program using the lessons gained while doing the first one.
On the basis of actual time s IBM conve took
40% l tha VAX conversion. The IBM conversion time
inc DEC20/VA VAX/IBM conversion minus the
time spend "undoing" the unnecessary VAX changes.
basis of post-learning curve I estimate t IBM conve would be reduc abou that
the VAX.
9
MONTE CARLO FORTRAN PROGRAM CONVERSION
VAX/IBM 4331 COMPARISON
DEC20 to VAX DEC20 to IBM
------------ ------------
Accuracy considerations in shift Same
from 36 bit to 32 bit fullword.
Changing from 5 char/word to Same
4 char/word for character strings
Logical bit manipulation cannot Same
be done on real parameters.
Free field "F" and "I" editing: Free-field "F" and "I" not
a) It is not FORMALLY supported. (list-directed
support on VAX. However, it I/O replaced them in this
works on the edition of the conversion; this required
compiler. input data syntax changes.)
b) Data fields must be separated
by commas (not just spaces).
Different random number Same
generator and syntax
Character mode conversion not ASCII/EBCDIC conversion must
needed to move files from DEC20 be done to move files from
to VAX. DEC20 to IBM.
Hex and Octal constants allowed Hex constants not allowed in
in assignment statements (same assignment statement (only in
as DEC20) DATA & PARAMETER statements).
"+" and "$" carriage control "+" and "$" carriage control
suppression allowed (same as suppression not allowed.
DEC20)
Changes needed to OPEN statement: Changes needed to OPEN statement:
a option diff disposition parameter
b) different ACCESS entry b) "." in file name not allowed
c) no DEVICE option (ex: gpc970.DAT)
d) different method of specifying c) No method of specifying
read-only file read-only in the OPEN
statement.
Comments allowed on an No allowed in IBM VS Fortran
instruction line following "!"
(same as DEC20)
ENCODE and DECODE supported as ENCODE and DECODE not supported.
extensions to standard FORTRAN (can be replaced by internal read/
write)
10
Trailing blanks in a format Handled differently on IBM--
literal that is continued on must be converted to yield the
another line. handled same as same output.
DEC20.
A "tab" in pos. 1 of an intitial A "tab" in pos. 1 is not allowed
or continuation line is allowed (VS Fortran has free-form option,
(same as DEC20) but this particular item is not
supported in it.)
11