\" @(#)m3 6.1 (Berkeley) 4/29/86
\"
NH
IMPLEMENTATION
PP
Ratfor
was originally written in
C[4]
on the
UC UNIX
operating system[5].
The language is specified by a context free grammar
and the compiler constructed using
the
UC YACC
compiler-compiler[6].
PP
The
Ratfor
grammar is simple and straightforward, being essentially
P1
prog : stat
| prog stat
stat : \f3if\fP (...) stat
| \f3if\fP (...) stat \f3else\fP stat
| \f3while\fP (...) stat
| \f3for\fP (...; ...; ...) stat
| \f3do\fP ... stat
| \f3repeat\fP stat
| \f3repeat\fP stat \f3until\fP (...)
| \f3switch\fP (...) { \f3case\fP ...: prog ...
\f3default\fP: prog }
| \f3return\fP
| \f3break\fP
| \f3next\fP
| digits stat
| { prog }
| anything unrecognizable
P2
The observation
that
Ratfor
knows no Fortran
follows directly from the rule that says a statement is
``anything unrecognizable''.
In fact most of Fortran falls into this category,
since any statement that does not begin with one of the keywords
is by definition ``unrecognizable.''
PP
Code generation is also simple.
If the first thing on a source line is
not a keyword
(like
UL if ,
UL else ,
etc.)
the entire statement is simply copied to the output
with appropriate character translation and formatting.
(Leading digits are treated as a label.)
Keywords cause only slightly more complicated actions.
For example, when
UL if
is recognized, two consecutive labels L and L+1
are generated and the value of L is stacked.
The condition is then isolated, and the code
P1
if (.not. (condition)) goto L
P2
is output.
The
ul
statement
part of the
UL if
is then translated.
When the end of the
statement is encountered
(which may be some distance away and include nested \f3if\fP's, of course),
the code
P1
L continue
P2
is generated, unless there is an
UL else
clause, in which case
the code is
P1
goto L+1
L continue
P2
In this latter case,
the code
P1
L+1 continue
P2
is produced after the
ul
statement
part of the
UL else.
Code generation for the various loops is equally simple.
PP
One might argue that more care should be taken
in code generation.
For example,
if there is no trailing
UL else ,
P1
if (i > 0) x = a
P2
should be left alone, not converted into
P1
if (.not. (i .gt. 0)) goto 100
x = a
100 continue
P2
But what are optimizing compilers for, if not to improve code?
It is a rare program indeed where this kind of ``inefficiency''
will make even a measurable difference.
In the few cases where it is important,
the offending lines can be protected by `%'.
PP
The use of a compiler-compiler is definitely the preferred method
of software development.
The language is well-defined,
with few syntactic irregularities.
Implementation is quite simple;
the original construction took under a week.
The language
is sufficiently simple, however, that an
ul
ad hoc
recognizer can be readily constructed to do the same job
if no compiler-compiler is available.
PP
The C version of
Ratfor
is used on
UC UNIX
and on the Honeywell
UC GCOS
systems.
C compilers are not as widely available as Fortran, however,
so there is also a
Ratfor
written in itself
and originally bootstrapped with the C version.
The
Ratfor
version
was written so as to translate into the portable subset
of Fortran described in [1],
so it is portable,
having been run essentially without change
on at least twelve distinct machines.
(The main restrictions of the portable subset are:
only one character per machine word;
subscripts in the
form
ul
c*v\(+-c;
avoiding expressions in places like
UC DO
loops;
consistency in subroutine argument usage,
and in
UC COMMON
declarations.
Ratfor
itself will not gratuitously generate non-standard Fortran.)
PP
The
Ratfor
version is about 1500 lines of
Ratfor
(compared to about 1000 lines of C);
this compiles into 2500 lines of Fortran.
This expansion ratio is somewhat higher than average,
since the compiled code contains unnecessary occurrences
of
UC COMMON
declarations.
The execution time of the
Ratfor
version is dominated by
two routines that read and write cards.
Clearly these routines could be replaced
by machine coded local versions;
unless this is done, the efficiency of other parts of the translation process
is largely irrelevant.
