puman2.n

早期freebsd实现

was expected before the keyword
.B begin
in the
.B for
statement.
If we examine the
.I statement
syntax chart on page 118 of the
Jensen-Wirth
.I "User Manual"
we will discover that
.B do
is a necessary part of the
.B for
statement.
Similarly, we could have referred to section C.3 of the
Jensen-Wirth
.I "User Manual"
to learn about the
.B for
statement and gotten the same information there.
It is often useful to refer to these syntax charts and to the
relevant sections of this book.
.PP
We can correct this problem by first scanning for the keyword
.B for
in the file and then substituting the keyword
.B do
to appear in front of the keyword
.B begin
there.
Thus:
.LS
:\*b/for\fR
	for i := 0 to lim begin
:\*bs/begin/do &\fR
	for i := 0 to lim do begin
:
.LE
The next error in the program is easy to pinpoint.
On line 18, we didn't hit the shift key and got a `9'
instead of a `)'.
The translator diagnosed that `x9'
was an undefined variable and, later,
that a `)' was missing in the statement.
It should be stressed that
.PI
is not suggesting that you should insert a `)' before the `;'.
It is only indicating that making this change will help it to be able to
continue analyzing the program so as to be able to diagnose further
errors.
You must then determine the true cause of the error and make the
appropriate correction to the source text.
.PP
This error also illustrates the fact that one error in the input may lead
to multiple error diagnostics.
.I Pi
attempts
to give only one diagnostic for each error,
but single errors in the input sometimes appear to be more than
one error.
It is also the case that
.PI
may not detect an error when it occurs, but may detect it later in
the input.
This would have happened
in this example if we had typed `x' instead of `x9'.
.PP
The translator next detected, on line 19, that the function
.I Round
and the variable
.I h
were undefined.
It does not know about
.I Round
because
.UP
normally distinguishes between upper and lower case.\*(dg
.FS
\*(dgIn ``standard'' Pascal no distinction is made based on case.
.FE
On
.UX
lower-case is preferred\*(dd,
.FS
\*(ddOne good reason for using lower-case is that it is easier to type.
.FE
and all keywords and built-in
.B procedure
and
.B function
names are composed of lower-case letters,
just as they are in the Jensen-Wirth
.I "Pascal Report" .
Thus we need to use the function
.I round
here.
As far as
.I h
is concerned,
we can see why it is undefined if we look back to line 9
and note that its definition was lost in the non-terminated
comment.
This diagnostic need not, therefore, concern us.
.PP
The next error which occurred in the program caused the translator
to insert a `;' before the statement calling
.I writeln
on line 23.
If we examine the program around the point of error we will see
that the actual error is that the keyword
.B until
and an associated expression have been omitted here.
Note that the diagnostic from the translator does not indicate the actual
error, and is somewhat misleading.
The translator made the correction which seemed to be most plausible.
As the omission of a `;' character is a common mistake,
the translator chose to indicate this as a possible fix here.
It later detected that the keyword
.B until
was missing, but not until it saw the keyword
.B end
on line 24.
The combination of these diagnostics indicate to us the true problem.
.PP
The final syntactic error message indicates that the translator needed an
.B end
keyword to match the
.B begin 
at line 15.
Since the
.B end
at line 24 is supposed to match this
.B begin ,
we can infer that another
.B begin
must have been mismatched, and have matched this
.B end .
Thus we see that we need an
.B end
to match the
.B begin
at line 16,
and to appear before the final
.B end .
We can make these corrections:
.LS
:\*b/x9/s//x)\fR
                y := exp(-x) * sin(i * x);
:\*b+s/Round/round\fR
                n := round(s * y) + h;
:\*b/write\fR
                        write(' ');
:\*b/\fR
                writeln('*')
:\*binsert\fR
                \*buntil n = 0;\fR
\&\*b.\fR
:\*b$\fR
end.
:\*binsert\fR
        \*bend\fR
\&\*b.\fR
:
.LE
.PP
At the end of each
.B procedure
or
.B function
and the end of the
.B program
the translator summarizes references to undefined variables
and improper usages of variables.
It also gives
warnings about potential errors.
In our program, the summary errors do not indicate any further problems
but the warning that
.I c
is unused is somewhat suspicious.
Examining the program we see that the constant was intended
to be used in the expression which is an argument to
.I sin ,
so we can correct this expression, and translate the program.
We have now made a correction for each diagnosed error
in our program.
.LS
:\*b?i ?s//c /\fR
		y := exp(-x) * sin(c * x);
:\*bwrite\fR
"bigger.p" 26 lines, 538 characters
:\*bquit\fR
% \*bpi bigger.p\fR
%
.LE
It should be noted that the translator suppresses warning
diagnostics for a particular
.B procedure ,
.B function
or the main
.B program
when it finds severe syntax errors in that part of the source
text.
This is to prevent possibly confusing and
incorrect warning diagnostics from being produced.
Thus these warning diagnostics may not appear in a program with
bad syntax errors until these errors are corrected.
.KS
.PP
We are now ready to execute our program for the first
time.
We will do so in the next section after giving a listing
of the corrected program for reference purposes.
.LS
% \*bcat -n bigger.p\fR
.so bigger6.p
%
.LE
.NH 2
Executing the second example
.PP
We are now ready to execute the second example.
The following output was produced by our first run.
.LS
% \*bpx\fR
.so bigout2
%
.LE
Here the interpreter is presenting us with a runtime error diagnostic.
It detected a `division by zero' at line 17.
Examining line 17, we see that we have written
the statement `x := d / i' instead of `x := d * i'.
We can correct this and rerun the program:
.LS
% \*bex bigger.p\fR
"bigger.p" 26 lines, 538 characters
:\*b17\fR
        x := d / i
:\*bs'/'*\fR
        x := d * i
:\*bwrite\fR
"bigger.p" 26 lines, 538 characters
:\*bq\fR
% \*bpix bigger.p\fR
.so bigout3
%
.LE
.KS
.PP
This appears to be the output we wanted.
We could now save the output in a file if we wished by using the shell
to redirect the output:
.LS
% \*bpx > graph\fR
.LE
.KE
We can use
.I cat
(1) to see the contents of the file graph.
We can also make a listing of the graph on the line printer without
putting it into a file, e.g.
.LS
% \*bpx | lpr\fR
.so bigout4
%
.LE
Note here that the statistics lines came out on our terminal.
The statistics line comes out on the diagnostic output (unit 2.)
There are two ways to get rid of the statistics line.
We can redirect the statistics message to the printer using the
syntax `|\|&' to the shell rather than `|', i.e.:
.LS
% \*bpx |\|& lpr\fR
%
.LE
or we can translate the program with the
.B p
option disabled on the command line as we did above.
This will disable all post-mortem dumping including the statistics line,
thus:
.LS
% \*bpi -p bigger.p\fR
% \*bpx | lpr\fR
%
.LE
This option also disables the statement limit which normally guards
against infinite looping.
You should not use it until your program is debugged.
Also if
.B p
is specified and an error occurs, you will
not get run time diagnostic information to help you
determine what the problem is.
.NH 2
Formatting the program listing
.PP
It is possible to use special lines within the source text of a program
to format the program listing.
An empty line (one with no characters on it) corresponds to a
`space' macro in an assembler, leaving a completely blank line
without a line number.
A line containing only a control-l (form-feed) character
will cause a page eject in the listing with the corresponding line number
suppressed.
This corresponds to an `eject' pseudo-instruction.
See also section 5.2 for details on the
.B n
and
.B i
options of
.PI .
.NH 2
Execution profiling
.PP
An execution profile consists of a structured listing of (all or part of)
a program with information about the number of times each statement in
the program was executed for a particular run of the program.
These profiles can be used for several purposes.
In a program which was abnormally terminated due to excessive looping
or recursion or by a program fault, the counts can facilitate location
of the error.
Zero counts mark portions of the program which were not executed;
during the early debugging stages they should prompt new test data or
a re-examination of the program logic.
The profile is perhaps most valuable, however, in drawing
attention to the (typically small)
portions of the program that dominate execution time.
This information can be used for source level optimization.
.SH
An example
.PP
A prime number is a number which is divisible only by itself and the
number one.
The program
.I primes ,
written by Niklaus Wirth,
determines the first few prime numbers.
In translating the program we have specified the
.B z
option to
.IX .
This option causes the translator to generate counters and count instructions
sufficient in number to determine the number of times each statement in the
program was executed.\*(dg
.FS
\*(dgThe counts
are completely accurate only in the absence of runtime errors and nonlocal
.B goto
statements.
This is not generally a problem, however, as in structured programs
nonlocal
.B goto
statements occur infrequently,
and counts are incorrect after abnormal termination only when the
.I "upward look"
described below to get a count passes a suspended call point.
.FE
When execution of the program completes, either normally or abnormally,
this count data is written to the file
.I pmon.out
in the current directory.\*(dd
.FS
\*(dd\c
.I Pmon.out
has a name similar to
.I mon.out
the monitor file produced by the profiling facility of the C compiler
.I cc
(1).
See
.I prof
(1) for a discussion of the C compiler profiling facilities.
.FE
It is then possible to prepare an execution profile by giving
.XP
the name of the file associated with this data, as was done in the following
example.
.LS
% \*bpix -l -z primes.p\fR
.so primeout1
%
.LE
.SH
Discussion
.PP
The header lines of the outputs of
.IX
and
.XP
in this example indicate the version of the translator and execution
profiler in use at the time this example was prepared.
The time given with the file name (also on the header line)
indicates the time of last modification of the program source file.
This time serves to
.I "version stamp"
the input program.
.I Pxp
also indicates the time at which the profile data was gathered.
.LS
% \*bpxp -z primes.p\fR
.so primeout2
%
.LE
.KE
.PP
To determine the number of times a statement was executed,
one looks to the left of the statement and finds the corresponding
vertical bar `|'.
If this vertical bar is labelled with a count then that count gives the 
number of times the statement was executed.
If the bar is not labelled, we look up in the listing to find the first
`|' which directly above the original one which has a count and that
is the answer.
Thus, in our example,
.I k
was incremented 157 times on line 18,
while the
.I write
procedure call on line 24 was executed 48 times as given by the count
on the
.B repeat .
.PP
More information on
.I pxp
can be found in its manual section
.XP
(1)
and in sections 5.4, 5.5 and 5.10.