f77

unix v7是最后一个广泛发布的研究型UNIX版本

as in the following example:
.DS I
real a(4)
double precision b,c
.sp .5
equivalence (a(1),b), (a(4),c)
.DE
Some machines (e.g., Honeywell 6000, IBM 360) require that double precision quantities be on double word boundaries;
other machines (e.g., IBM 370), run inefficiently if this alignment rule is not observed.
It is possible to tell which equivalenced and common variables suffer from a forced odd
alignment, but every double precision argument would have to be assumed on a bad boundary.
To load such a quantity on some machines,
it would be necessary to use separate operations to move the upper and lower halves
into the halves of an aligned temporary, then to load that double precision temporary; the reverse would be
needed to store a result.
We have chosen to require that all double precision real and complex quantities
fall on even word boundaries on machines with corresponding hardware requirements,
and to issue a diagnostic if the source code demands a violation of the rule.
.NH 2
Dummy Procedure Arguments
.IP
If any argument of a procedure is of type character,
all dummy procedure arguments of that procedure must be declared
in an
.B external
statement.
This requirement arises as a subtle corollary of the way we represent character string arguments
and of the one-pass nature of the compiler.
A warning is printed if a dummy procedure is not declared
.B external.
Code is correct if there are no
.B character
arguments.
.NH 2
T and TL Formats
.IP
The implementation of the
.B t
(absolute tab)
and
.B tl
(leftward tab)
format codes
is defective.
These codes allow rereading or rewriting part of the
record which has already been processed.
(Section 6.3.2 in the Appendix.)
The implementation uses seeks,
so if the unit is not one which allows seeks,
such as a terminal,
the program is in error.
(People who can make a case for using
.B tl
should let us know.)
A benefit of the implementation chosen is
that there is no upper limit on the length of
a record,
nor is it necessary to predeclare any record
lengths except where specifically required
by Fortran or the operating system.
.NH 1
INTER-PROCEDURE INTERFACE
.PP
To be able to write C procedures that call or are called by Fortran procedures,
it is necessary to know the conventions for procedure names,
data representation,
return values,
and argument lists that the compiled code obeys.
.NH 2
Procedure Names
.PP
On
.UX
systems,
the name of a common block or a Fortran procedure
has an underscore appended to it by the compiler
to distinguish it from a C procedure or external variable
with the same user-assigned name.
Fortran library procedure names have embedded underscores to avoid clashes
with user-assigned subroutine names.
.NH 2
Data Representations
.PP
The following is a table of corresponding Fortran and C declarations:
.KS
.TS
center;
c c
l l.
Fortran	C
.sp .5
integer\(**2 x	short int x;
integer x	long int x;
logical x	long int x;
real x	float x;
double precision x	double x;
complex x	struct { float r, i; } x;
double complex x	struct { double dr, di; } x;
character\(**6 x	char x[6];
.TE
.KE
(By the rules of Fortran,
.B integer,
.B logical,
and
.B real
data occupy the same amount of memory).
.NH 2
Return Values
.PP
A function of type
.B integer,
.B logical,
.B real,
or
.B "double precision"
declared as a C function that returns the corresponding type.
A
.B complex
or
.B "double complex"
function is equivalent to a C routine
with an additional
initial argument that points to the place where the return value is to be stored.
Thus,
.DS
complex function f( . . . )
.DE
is equivalent to
.DS
f_(temp, . . .)
struct { float r, i; } \(**temp;
 . . .
.DE
.DE
A character-valued function is equivalent to a C routine with
two extra initial arguments:
a data address and a length.
Thus,
.DS
character\(**15 function g( . . . )
.DE
is equivalent to
.DS
g_(result, length, . . .)
char result[ ];
long int length;
 . . .
.DE
and could be invoked in C by
.DS
char chars[15];
 . . .
g_(chars, 15L, . . . );
.DE
Subroutines are invoked as if they were \fBinteger\fR-valued functions
whose value specifies which alternate return to use.
Alternate return arguments (statement labels) are not passed to the function,
but are used to do an indexed branch in the calling procedure.
(If the subroutine has no entry points with alternate return arguments,
the returned value is undefined.)
The statement
.DS
call nret(\(**1, \(**2, \(**3)
.DE
is treated exactly as if it were the computed
.B goto
.DS
goto (1, 2, 3),  nret( )
.DE
.NH 2
Argument Lists
.PP
All Fortran arguments are passed by address.
In addition,
for every argument that is of type character or
that is a dummy procedure,
an argument giving the length of the value is passed.
(The string lengths are
.B "long int"
quantities passed by value).
The order of arguments is then:
.DS
Extra arguments for complex and character functions
Address for each datum or function
A \fBlong int\fR for each character or procedure argument
.DE
Thus, the call in
.DS
external f
character\(**7 s
integer b(3)
 . . .
call sam(f, b(2), s)
.DE
is equivalent to that in
.DS
int f();
char s[7];
long int b[3];
 . . .
sam_(f, &b[1], s, 0L, 7L);
.DE
Note that the first element of a C array always has subscript zero,
but Fortran arrays begin at 1 by default.
Fortran arrays are stored in column-major order, C arrays are stored in row-major order.
.NH 1
FILE FORMATS
.NH 2
Structure of Fortran Files
.PP
Fortran requires four kinds of external files:
sequential formatted and unformatted,
and direct formatted and unformatted.
On
.UX
systems,
these are all implemented as ordinary files
which are assumed to have the proper
internal structure.
.PP
Fortran I/O is based on ``records''.
When a direct file is opened in a Fortran program,
the record length of the records must be given,
and this is used by the Fortran I/O system to
make the file look as if it is made up of records
of the given length.
In the special case that the record length is given
as 1,
the files are not considered to be divided into records,
but are treated as byte-addressable byte strings;
that is,
as ordinary
.UX
file system files.
(A read or write request on such a file keeps consuming bytes until
satisfied, rather than being restricted to a single record.)
.PP
The peculiar requirements on sequential unformatted files
make it unlikely that they will ever be read or written by any means except Fortran I/O statements.
Each record is preceded and followed by
an integer containing the record's length in bytes.
.PP
The Fortran I/O system breaks sequential formatted files
into records while reading by using each newline
as a record separator.
The result of reading off the end of a record is undefined according to the Standard.
The I/O system is permissive and
treats the record as being extended by blanks.
On output,
the I/O system will write a newline at the end of each
record.
It is also possible for programs to write newlines
for themselves.
This is an error,
but the only effect will be that the single record
the user thought he wrote will be treated as
more than one record when being read or
backspaced over.
.NH 2
Portability Considerations
.PP
The Fortran I/O system uses only the facilities of the
standard C I/O library,
a widely available and fairly portable package,
with the following two nonstandard features:
The I/O system needs to know whether a file
can be used for direct I/O,
and whether or not it is possible to backspace.
Both of these facilities are implemented
using the
.B fseek
routine,
so there is a routine
.B canseek
which determines if
.B fseek
will have the desired effect.
Also, the
.B inquire
statement provides the user
with the ability to find out if two files are the
same,
and to get the name of an already opened file
in a form which would enable the program to reopen
it.
(The
.UX
operating system implementation attempts to determine the full pathname.)
Therefore there are two routines which
depend on facilities of the operating system
to provide these two services.
In any case,
the I/O system
runs on the PDP-11, VAX-11/780, and Interdata 8/32
.UX
systems.
.NH 2
Pre-Connected Files and File Positions
.PP
Units 5, 6, and 0 are preconnected when the program starts.
Unit 5 is connected to the standard input,
unit 6 is connected to the standard output,
and unit 0 is connected to the standard error unit.
All are connected for sequential formatted I/O.
.PP
All the other units are also preconnected when execution
begins.
Unit
.I n
is connected to a file named \fBfort.\fIn\fR.
These files need not exist,
nor will they be created unless their units are used
without first executing an
.B open.
The default connection is for sequential formatted I/O.
.PP
The Standard does not specify where a file which has been explicitly \fBopen\fRed
for sequential I/O is initially positioned.
In fact,
the I/O system attempts to position the file at the end,
so a
.B write
will append to the file and a
.B read
will result in an end-of-file indication.
To position a file to its beginning,
use a
.B rewind
statement.
The preconnected units
0, 5, and 6 are positioned as they come
from the program's parent process.
.SG
.SH
REFERENCES
.LP
.IP 1.
\fISigplan Notices \fB11\fR, No.3 (1976),
as amended in X3J3 internal documents through ``/90.1''.
.IP 2.
\fIUSA Standard FORTRAN, USAS X3.9-1966\fR,
New York: United States of America Standards Institute, March 7, 1966.
Clarified in
\fIComm. ACM \fB12,\fR 289 (1969)
and
\fIComm. ACM \fB14, \fR 628 (1971).
.IP 3.
B. W. Kernighan and D. M. Ritchie,
.I
The C Programming Language,
.R
Englewood Cliffs: Prentice-Hall (1978).
.IP 4.
D. M. Ritchie, private communication.
.IP 5.
S. C. Johnson,
``A Portable Compiler: Theory and Practice'',
Proc. 5th ACM Symp. on Principles of Programming Languages
(January 1978).
.IP 6.
S. I. Feldman,
``An Informal Description of EFL'',
internal memorandum.
.IP 7.
B. W. Kernighan,
``RATFOR \(em A Preprocessor for a Rational Fortran'',
.I
Bell Laboratories Computing Science Technical Report #55,
.R
(January 1977).
.IP 8.
D. M. Ritchie, private communication.
.bp
.SH
APPENDIX.  Differences Between Fortran 66 and Fortran 77
.PP
The following is a very brief description of the differences
between the 1966 [2] and the 1977 [1] Standard languages.
We assume that the reader is familiar with Fortran 66.
We do not pretend to be complete, precise,
or unbiased,
but plan to describe what we feel are the most important aspects of the new language.
At present the only current information on the 1977 Standard is in publications of the X3J3 Subcommittee
of the
American National Standards Institute.
The following information is from the ``/92'' document.
This draft Standard is written in English rather than a meta-language, but it is forbidding
and legalistic.
No tutorials or textbooks are available yet.
.NH 0
Features Deleted from Fortran 66
.NH 2
Hollerith
.IP
All notions of ``Hollerith''
(\fIn\|\fBh\fR)
as data
have been officially removed, although our compiler, like almost all in the foreseeable future,
will continue to support this archaism.
.NH 2
Extended Range
.IP
In Fortran 66, under a set of very restrictive and rarely-understood conditions, it is permissible
to jump out of the range of a
.B do
loop, then jump back into it.
Extended range has been removed in the Fortran 77 language.
The restrictions are so special, and the implementation of extended range is so unreliable in many compilers,
that this change really counts as no loss.
.NH 1
Program Form
.NH 2
Blank Lines
.IP
Completely blank lines are now legal comment lines.
.NH 2
Program and Block Data Statements
.IP
A main program may now begin with a statement that gives that program an external name:
.DS
program work
.DE
Block data procedures may also have names.
.DS
block data stuff
.DE
There is now a rule that only
.I one
unnamed
block data procedure may appear in a program.
(This rule is not enforced by our system.)
The Standard does not specify the effect of the program and block data names,
but they are clearly intended to aid conventional loaders.
.NH 2
ENTRY Statement
.IP
Multiple entry points are now legal.
Subroutine and function subprograms may have additional entry points,
declared by an
.B entry
statement with an optional argument list.
.DS
entry extra(a, b, c)
.DE
Execution begins at the first statement following the
.B entry
line.
All variable declarations must precede all executable statements in the procedure.
If the procedure begins with a
.B subroutine
statement,
all entry points are subroutine names.
If it begins with a
.B function
statement, each entry is a function entry point,
with type determined by the type declared for the entry name.
If any entry is a character-valued function,
then all entries must be.
In a function, an entry name of the same type as that where control entered
must be assigned a value.
Arguments do not retain their values between calls.
(The ancient trick of calling one entry point with a large number of arguments
to cause the procedure to ``remember'' the locations of those arguments,
then invoking an entry with just a few arguments for later calculation,
is still illegal.
Furthermore, the trick doesn't work in our implementation,
since arguments are not kept in static storage.)
.NH 2
DO Loops
.IP
.B do
variables and range parameters may now be of integer, real, or double precision types.
(The use of floating point
.B do
variables is very dangerous
because of the possibility of unexpected roundoff,
and we strongly recommend against their use).
The action of the
.B do
statement is now defined for all values of the
.B do
parameters.
The statement
.DS
do 10 i = l, u, d
.DE
performs
$ max (0^,^ left floor ( u - l ) / d^ right floor )$
iterations.
The
.B do
variable has a predictable value when exiting a loop:
the value at the time a
.B goto
or
.B return
terminates the loop;
otherwise
the value that failed the limit test.
.NH 2
Alternate Returns