MirOS Manual: 07.pascal(PSD)


               Berkeley Pascal User's Manual
                  Version 3.1 - April 1986

    William N. Joy=, Susan L. Graham, Charles B. Haley=,
       Marshall Kirk McKusick, and Peter B. Kessler=

                 Computer Science Division
            Department of Electrical Engineering
                    and Computer Science
             University of California, Berkeley
                Berkeley, California  94720

                          ABSTRACT

          Berkeley Pascal is designed  for  interactive
     instructional  use  and  runs  on  the  PDP/11 and
     VAX/11 computers. Interpretive code  is  produced,
     providing  fast  translation  at  the  expense  of
     slower execution speed. There is also a fully com-
     patible compiler for the VAX/11. An execution pro-
     filer and Wirth's cross reference program are also
     available with the system.

          The system supports full Pascal. The language
     accepted  is `standard' Pascal, and a small number
     of extensions. There is an option to suppress  the
     extensions. The extensions include a separate com-
     pilation facility  and  the  ability  to  link  to
     object   modules   produced   from   other  source
     languages.

          The User's Manual gives  a  list  of  sources
     relating to the UNIX- system, the Pascal language,
     and  the Berkeley Pascal system. Basic usage exam-
     ples are provided for the  Pascal  components  pi,
     px,  pix, pc, and pxp. Errors commonly encountered
_________________________
Copyright 1977, 1979, 1980, 1983 W. N. Joy, S. L.  Gra-
ham, C. B. Haley, M. K. McKusick, P. B. Kessler
=Author's current addresses: William Joy: Sun Microsys-
tems,  2550  Garcia  Ave.,  Mountain  View,  CA  94043;
Charles Haley: S & B Associates, 1110 Centennial  Ave.,
Piscataway,  NJ   08854;  Peter Kessler: Xerox Research
Park, Palo Alto, CA
-  UNIX  is a registered trademark of AT&T Bell Labora-
tories in the USA and other countries.

                        July 4, 2014

PS1:4-2                        Berkeley Pascal User's Manual

     in these programs are discussed. Details are given
     of  special  considerations due to the interactive
     implementation. A number of examples are  provided
     including  many  dealing  with  input/output.   An
     appendix supplements Wirth's Pascal Report to form
     the full definition of the Berkeley implementation
     of the language.

Introduction

     The Berkeley Pascal  User's  Manual  consists  of  five
major sections and an appendix. In section 1 we give sources
of information about UNIX, about  the  programming  language
Pascal,   and  about  the  Berkeley  implementation  of  the
language. Section 2 introduces the  Berkeley  implementation
and  provides  a  number  of  tutorial  examples.  Section 3
discusses the error diagnostics produced by the  translators
pc  and  pi,  and  the  runtime  interpreter  px.  Section 4
describes  input/output  with  special  attention  given  to
features  of  the interactive implementation and to features
unique to UNIX. Section 5 gives details on the components of
the  system  and  explanation  of  all relevant options. The
User's Manual concludes with an appendix to  Wirth's  Pascal
Report  with  which  it  forms  a  precise definition of the
implementation.

History of the implementation

     The first Berkeley system was written by  Ken  Thompson
in  early 1976. The main features of the present system were
implemented by Charles Haley  and  William  Joy  during  the
latter  half  of  1976. Earlier versions of this system have
been in use since January, 1977.

     The system was moved to the VAX-11 by Peter Kessler and
Kirk  McKusick  with  the  porting of the interpreter in the
spring of 1979, and the implementation of  the  compiler  in
the summer of 1980.

1. Sources of information

     This section lists the resources available for informa-
tion  about general features of UNIX, text editing, the Pas-
cal language, and the Berkeley Pascal  implementation,  con-
cluding  with  a list of references. The available documents
include both so-called standard documents  -  those  distri-
buted  with  all  UNIX  system - and documents (such as this
one) written at Berkeley.

Berkeley Pascal User's Manual                        PS1:4-3

1.1. Where to get documentation

     Current documentation for most of the  UNIX  system  is
available  ``on  line'' at your terminal. Details on getting
such documentation interactively are given in section 1.3.

1.2. Documentation describing UNIX

     The  following  documents  are  those  recommended   as
tutorial  and  reference  material about the UNIX system. We
give  the  documents  with  the  introductory  and  tutorial
materials first, the reference materials last.

UNIX For Beginners - Second Edition

     This document is the basic tutorial for UNIX  available
with the standard system.

Communicating with UNIX

     This is also a basic tutorial on the system and assumes
no  previous  familiarity  with computers; it was written at
Berkeley.

An introduction to the C shell

     This document introduces csh, the shell in  common  use
at Berkeley, and provides a good deal of general description
about the way in which the system functions. It  provides  a
useful glossary of terms used in discussing the system.

UNIX Programmer's Manual

     This manual is the major source of details on the  com-
ponents  of the UNIX system. It consists of an Introduction,
a permuted index, and eight command sections. Section 1 con-
sists  of  descriptions of most of the ``commands'' of UNIX.
Most of the other sections have  limited  relevance  to  the
user  of Berkeley Pascal, being of interest mainly to system
programmers.

     UNIX documentation often refers the reader to  sections
of  the  manual. Such a reference consists of a command name
and a section number or name. An example of such a reference
would  be:  ed (1). Here ed is a command name - the standard
UNIX text editor, and `(1)' indicates that its documentation
is in section 1 of the manual.

     The pieces of the Berkeley Pascal system are pi (1), px
(1),  the combined Pascal translator and interpretive execu-
tor pix (1), the Pascal compiler pc (1), the  Pascal  execu-
tion  profiler  pxp (1), and the Pascal cross-reference gen-
erator pxref (1).

PS1:4-4                        Berkeley Pascal User's Manual

     It is possible to obtain a copy of a manual section  by
using  the  man (1) command. To get the Pascal documentation
just described one could issue the command:

        % man pi

to the shell. The user input here is shown in bold face; the
`%  ',  which  was printed by the shell as a prompt, is not.
Similarly the command:

        % man man

asks the man command to describe itself.

1.3. Text editing documents

     The following documents introduce the various UNIX text
editors.  Most Berkeley users use a version of the text edi-
tor ex; either edit, which is a version of ex  for  new  and
casual users, ex itself, or vi (visual) which focuses on the
display editing portion of ex.

A Tutorial Introduction to the UNIX Text Editor

     This document,  written  by  Brian  Kernighan  of  Bell
Laboratories,  is a tutorial for the standard UNIX text edi-
tor ed. It introduces you to the basics of text editing, and
provides  enough  information  to  meet  day-to-day  editing
needs, for ed users.

Edit: A tutorial

     This introduces the use of edit, an editor  similar  to
ed  which  provides a more hospitable environment for begin-
ning users.

Ex/edit Command Summary

     This summarizes the features of the editors ex and edit
in  a concise form.  If you have used a line oriented editor
before this summary alone may be enough to get you started.

Ex Reference Manual - Version 3.7

     A complete reference on the features of ex and edit.

An Introduction to Display Editing with Vi

     Vi is a display oriented text editor.  It can  be  used
on  most  any  CRT terminal, and uses the screen as a window
into the file you are editing.  Changes you make to the file

Berkeley Pascal User's Manual                        PS1:4-5

are  reflected  in what you see.  This manual serves both as
an introduction to editing with vi and a reference manual.

Vi Quick Reference

     This reference card is a handy quick guide to  vi;  you
should get one when you get the introduction to vi.

1.4. Pascal documents - The language

     This section describes  the  documents  on  the  Pascal
language  which are likely to be most useful to the Berkeley
Pascal user. Complete references  for  these  documents  are
given in section 1.7.

Pascal User Manual

     By Kathleen Jensen and Niklaus Wirth, the  User  Manual
provides  a  tutorial  introduction  to  the features of the
language Pascal, and serves as an excellent  quick-reference
to  the language. The reader with no familiarity with Algol-
like languages may prefer  one  of  the  Pascal  text  books
listed below, as they provide more examples and explanation.
Particularly important here are pages 116-118  which  define
the  syntax of the language. Sections 13 and 14 and Appendix
F pertain only to the 6000-3.4 implementation of Pascal.

Pascal Report

     By Niklaus Wirth, this document is bound with the  User
Manual. It is the guiding reference for implementors and the
fundamental definition of  the  language.  Some  programmers
find this report too concise to be of practical use, prefer-
ring the User Manual as a reference.

Books on Pascal

     Several good books which teach Pascal or use  it  as  a
medium are available. The books by Wirth Systematic Program-
ming and Algorithms + Data Structures = Programs use  Pascal
as  a  vehicle  for  teaching programming and data structure
concepts respectively.  They  are  both  recommended.  Other
books on Pascal are listed in the references below.

1.5. Pascal documents - The Berkeley Implementation

     This  section  describes  the  documentation  which  is
available describing the Berkeley implementation of Pascal.

User's Manual

     The document you are reading is the User's  Manual  for
Berkeley  Pascal.  We  often refer the reader to the Jensen-

PS1:4-6                        Berkeley Pascal User's Manual

Wirth User Manual mentioned above, a different document with
a similar name.

Manual sections

     The  sections  relating   to   Pascal   in   the   UNIX
Programmer's Manual are pix (1), pi (1), pc (1), px (1), pxp
(1), and pxref (1). These sections  give  a  description  of
each  program,  summarize  the  available  options, indicate
files used by the program, give  basic  information  on  the
diagnostics produced and include a list of known bugs.

Implementation notes

     For those interested in the  internal  organization  of
the Berkeley Pascal system there are a series of Implementa-
tion Notes describing these details. The Berkeley Pascal PXP
Implementation Notes describe the Pascal interpreter px; and
the Berkeley Pascal PX  Implementation  Notes  describe  the
structure of the execution profiler pxp.

1.6. References

UNIX Documents

     Communicating With UNIX
     Computer Center
     University of California, Berkeley
     January, 1978.

     Ricki Blau and James Joyce
     Edit: a tutorial
     UNIX User's Supplementary Documents (USD), 14
     University of California, Berkeley, CA. 94720
     April, 1986.

     Ex/edit Command Summary
     Computer Center
     University of California, Berkeley
     August, 1978.

     William Joy
     Ex Reference Manual - Version 3.7
     UNIX User's Supplementary Documents (USD), 16
     University of California, Berkeley, CA. 94720
     April, 1986.

     William Joy

Berkeley Pascal User's Manual                        PS1:4-7

     An Introduction to Display Editing with Vi
     UNIX User's Supplementary Documents (USD), 15
     University of California, Berkeley, CA. 94720
     April, 1986.

     William Joy
     An Introduction to the C shell (Revised)
     UNIX User's Supplementary Documents (USD), 4
     University of California, Berkeley, CA. 94720
     April, 1986.

     Brian W. Kernighan
     UNIX for Beginners - Second Edition
     UNIX User's Supplementary Documents (USD), 1
     University of California, Berkeley, CA. 94720
     April, 1986.

     Brian W. Kernighan
     A Tutorial Introduction to the UNIX Text Editor
     UNIX User's Supplementary Documents (USD), 12
     University of California, Berkeley, CA. 94720
     April, 1986.

     Dennis M. Ritchie and Ken Thompson
     The UNIX Time Sharing System
     Reprinted from Communications of the ACM July 1974 in
     UNIX Programmer's Supplementary Documents, Volume 2 (PS2), 1
     University of California, Berkeley, CA. 94720
     April, 1986.

Pascal Language Documents

     Cooper and Clancy
     Oh! Pascal!, 2nd Edition
     W. W. Norton & Company, Inc.
     500 Fifth Ave., NY, NY. 10110
     1985, 475 pp.

     Cooper
     Standard Pascal User Reference Manual
     W. W. Norton & Company, Inc.
     500 Fifth Ave., NY, NY. 10110
     1983, 176 pp.

     Kathleen Jensen and Niklaus Wirth
     Pascal - User Manual and Report

PS1:4-8                        Berkeley Pascal User's Manual

     Springer-Verlag, New York.
     1975, 167 pp.

     Niklaus Wirth
     Algorithms + Data structures = Programs
     Prentice-Hall, New York.
     1976, 366 pp.

Berkeley Pascal documents

     The following documents are available from the Computer
Center Library at the University of California, Berkeley.

     William N. Joy
     Berkeley Pascal PX Implementation Notes
     Version 1.1, April 1979.
     (Vax-11 Version 2.0 By Kirk McKusick, December, 1979)

     William N. Joy
     Berkeley Pascal PXP Implementation Notes
     Version 1.1, April 1979.

2. Basic UNIX Pascal

     The following sections  explain  the  basics  of  using
Berkeley  Pascal. In examples here we use the text editor ex
(1). Users of the text editor ed should have little  trouble
following  these examples, as ex is similar to ed. We use ex
because it allows us to make clearer examples.- The new UNIX
user  will  find  it  helpful to read one of the text editor
documents described in section 1.4  before  continuing  with
this section.

2.1. A first program

     To prepare a program for Berkeley Pascal we first  need
to  have  an account on UNIX and to `login' to the system on
this account. These procedures are described  in  the  docu-
ments Communicating with UNIX and UNIX for Beginners.

     Once we are logged in we need to choose a name for  our
program;  let  us call it `first' as this is the first exam-
ple. We must also choose a name for the file  in  which  the
program  will be stored. The Berkeley Pascal system requires
_________________________
- Users with CRT terminals should find  the  editor  vi
more  pleasant  to use; we do not show its use here be-
cause its display oriented nature makes it difficult to
illustrate.

Berkeley Pascal User's Manual                        PS1:4-9

that programs reside in files which have names  ending  with
the sequence `.p' so we will call our file `first.p'.

     A sample editing session  to  create  this  file  would
begin:

        % ex first.p
        "first.p" [New file]
        :

We didn't expect the file to exist, so the error  diagnostic
doesn't bother us. The editor now knows the name of the file
we are creating. The `:' prompt indicates that it  is  ready
for command input. We can add the text for our program using
the `append' command as follows.

        :append
        program first(output)
        begin
                writeln('Hello, world!')
        end.
        .
        :

The line containing the single `.' character here  indicated
the  end of the appended text. The `:' prompt indicates that
ex is ready for another command. As the editor operates in a
temporary  work space we must now store the contents of this
work space in the file `first.p' so we can  use  the  Pascal
translator and executor pix on it.

        :write
        "first.p" [New file] 4 lines, 59 characters
        :quit
        %

We wrote out the file from the edit  buffer  here  with  the
`write'  command,  and  ex indicated the number of lines and
characters written. We then quit the editor, and now have  a
prompt from the shell.=

_________________________
= Our examples here assume you are using csh.

PS1:4-10                       Berkeley Pascal User's Manual

     We are ready to try to translate and execute  our  pro-
gram.

        % pix first.p
        Insert output of firstout here.
        %

     The translator first printed a syntax error diagnostic.
The  number 2 here indicates that the rest of the line is an
image of the second line of our program. The  translator  is
saying  that  it  expected  to find a `;' before the keyword
begin on this line. If we look at the Pascal  syntax  charts
in  the  Jensen-Wirth  User Manual, or at some of the sample
programs therein, we will see that we have omitted the  ter-
minating  `;'  of the program statement on the first line of
our program.

     One other thing to notice about the error diagnostic is
the  letter  `e'  at  the  beginning. It stands for `error',
indicating that our input was not  legal  Pascal.  The  fact
that  it  is  an  `e'  rather than an `E' indicates that the
translator managed to recover from this  error  well  enough
that generation of code and execution could take place. Exe-
cution is possible whenever no fatal `E' errors occur during
translation.  The other classes of diagnostics are `w' warn-
ings, which do not necessarily indicate errors in  the  pro-
gram,  but  point out inconsistencies which are likely to be
due to program bugs, and `s' standard-Pascal violations.+

     After completing the  translation  of  the  program  to
interpretive  code,  the Pascal system indicates that execu-
tion of the translated program began. The  output  from  the
execution  of the program then appeared. At program termina-
tion, the Pascal runtime  system  indicated  the  number  of
statements  executed,  and the amount of cpu time used, with
the resolution of the latter being 1/60'th of a second.

     Let us now fix the error in the program  and  translate
it to a permanent object code file obj using pi. The program
pi translates Pascal programs but  stores  the  object  code
instead of executing it*.
_________________________
+The standard Pascal warnings occur only when the asso-
ciated  s translator option is enabled. The s option is
discussed in sections 5.1 and A.6 below. Warning  diag-
nostics  are  discussed  at the end of section 3.2, the
associated w option is described in section 5.2.
*This  script indicates some other useful approaches to
debugging Pascal programs. As in ed we can shorten com-
mands in ex to an initial prefix of the command name as
we did with the substitute command here. We  have  also

Berkeley Pascal User's Manual                       PS1:4-11

        % ex first.p
        "first.p" 4 lines, 59 characters
        :1 print
        program first(output)
        :s/$/;
        program first(output);
        :write
        "first.p" 4 lines, 60 characters
        :quit
        % pi first.p
        %

If we now use the UNIX ls list files command we can see what
files we have:

        % ls
        first.p
        obj
        %

The file `obj' here contains the Pascal interpreter code. We
can execute this by typing:

        % px obj
        Insert output of firstobjout here.
        %

Alternatively, the command:

        % obj

will have the same effect. Some examples of  different  ways
to execute the program follow.

        % px
        Insert output of firstobjout here.
        % pi -p first.p
        % px obj
        Insert output of firstobjout2 here.
        % pix -p first.p
        Insert output of firstobjout2 here.
        %

     Note that px will assume that `obj' is the file we wish
_________________________
used the `!' shell escape command here to execute other
commands with a shell without leaving the editor.

PS1:4-12                       Berkeley Pascal User's Manual

to execute if we don't  tell  it  otherwise.  The  last  two
translations  use  the -p no-post-mortem option to eliminate
execution statistics and `Execution begins'  and  `Execution
terminated'  messages.  See section 5.2 for more details. If
we now look at the files in our directory we will see:

        % ls
        first.p
        obj
        %

We can give our object program a name other  than  `obj'  by
using  the  move  command  mv  (1). Thus to name our program
`hello':

        % mv obj hello
        % hello
        Hello, world!
        % ls
        first.p
        hello
        %

Finally we can get rid of the Pascal object  code  by  using
the rm (1) remove file command, e.g.:

        % rm hello
        % ls
        first.p
        %

     For small programs which are being developed pix  tends
to  be  more  convenient  to  use than pi and px. Except for
absence of the obj file after a pix run, a  pix  command  is
equivalent  to  a  pi  command followed by a px command. For
larger programs, where a number of  runs  testing  different
parts  of  the  program are to be made, pi is useful as this
obj file can be executed any desired number of times.

2.2. A larger program

     Suppose that we have used the editor to  put  a  larger
program  in  the  file  `bigger.p'. We can list this program
with line numbers by using the program cat-n i.e.:

        % cat -n bigger.p
        Insert output of bigger3.p here.
        %

Berkeley Pascal User's Manual                       PS1:4-13

This program is similar to program 4.9 on  page  30  of  the
Jensen-Wirth  User  Manual.  A  number of problems have been
introduced into this example for pedagogical reasons.

     If we attempt to  translate  and  execute  the  program
using pix we get the following response:

        % pix bigger.p
        Insert output of bigout1 here.
        %

     Since there were fatal `E' errors in  our  program,  no
code was generated and execution was necessarily suppressed.
One thing which would be useful at this point is  a  listing
of  the  program with the error messages. We can get this by
using the command:

        % pi -l bigger.p

There is no point in using pix here, since we know there are
fatal  errors  in the program. This command will produce the
output at our terminal. If we are at a terminal  which  does
not  produce  a  hard copy we may wish to print this listing
off-line on a line printer. We can do this with the command:

        % pi -l bigger.p | lpr

     In the next few sections  we  will  illustrate  various
aspects  of  the  Berkeley  Pascal system by correcting this
program.

2.3. Correcting the first errors

     Most of the errors which occurred in this program  were
syntactic  errors,  those in the format and structure of the
program rather than its content. Syntax errors  are  flagged
by  printing the offending line, and then a line which flags
the location at which an error was detected. The  flag  line
also gives an explanation stating either a possible cause of
the error, a simple action which can  be  taken  to  recover
from  the error so as to be able to continue the analysis, a
symbol which was expected at the point of error, or an indi-
cation that the input was `malformed'. In the last case, the
recovery may skip ahead  in  the  input  to  a  point  where
analysis of the program can continue.

     In this example, the first error  diagnostic  indicates
that  the  translator  detected  a comment within a comment.

PS1:4-14                       Berkeley Pascal User's Manual

While this is not considered an error in `standard'  Pascal,
it  usually  corresponds to an error in the program which is
being translated. In this case, we have accidentally omitted
the  trailing `*)' of the comment on line 8. We can begin an
editor session to correct this problem by doing:

        % ex bigger.p
        "bigger.p" 24 lines, 512 characters
        :8s/$/ *)
                s = 32;       (* 32 character width for interval [x, x+1] *)
        :

     The second diagnostic, given after line  16,  indicates
that the keyword do was expected before the keyword begin in
the for statement. If we examine the statement syntax  chart
on page 118 of the Jensen-Wirth User Manual we will discover
that do is a necessary part of the for statement. Similarly,
we  could  have  referred to section C.3 of the Jensen-Wirth
User Manual to learn about the 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.

     We can correct this problem by first scanning  for  the
keyword for in the file and then substituting the keyword do
to appear in front of the keyword begin there. Thus:

        :/for
                for i := 0 to lim begin
        :s/begin/do &
                for i := 0 to lim do begin
        :

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 state-
ment. It should be stressed that pi is not  suggesting  that
you  should insert a `)' before the `;'. It is only indicat-
ing that making this change will help it to be able to  con-
tinue  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.

     This error also illustrates the fact that one error  in
the  input  may  lead  to  multiple  error  diagnostics.  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.

Berkeley Pascal User's Manual                       PS1:4-15

This would have happened in this example if we had typed `x'
instead of `x9'.

     The translator next detected,  on  line  19,  that  the
function  Round  and  the variable h were undefined. It does
not know about Round because Berkeley Pascal  normally  dis-
tinguishes between upper and lower case.+ On UNIX lower-case
is preferred*, and all keywords and built-in  procedure  and
function  names  are composed of lower-case letters, just as
they are in the Jensen-Wirth Pascal Report. Thus we need  to
use  the  function  round here. As far as 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 com-
ment. This diagnostic need not, therefore, concern us.

     The next error which occurred in the program caused the
translator to insert a `;' before the statement calling wri-
teln on line 23. If we examine the program around the  point
of  error we will see that the actual error is that the key-
word 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 plau-
sible. As the omission of a `;' character is a  common  mis-
take,  the  translator  chose to indicate this as a possible
fix here. It later detected that the keyword until was miss-
ing,  but  not  until it saw the keyword end on line 24. The
combination of these diagnostics indicate  to  us  the  true
problem.

     The final syntactic error message  indicates  that  the
translator  needed an end keyword to match the begin at line
15. Since the end at line  24  is  supposed  to  match  this
begin,  we  can  infer  that  another  begin  must have been
mismatched, and have matched this end. Thus we see  that  we
need  an  end  to  match the begin at line 16, and to appear
before the final end. We can make these corrections:

        :/x9/s//x)
                        y := exp(-x) * sin(i * x);
        :+s/Round/round
                        n := round(s * y) + h;
        :/write
                                write(' ');
        :/
                        writeln('*')
_________________________
+In ``standard'' Pascal no distinction is made based on
case.
*One  good  reason  for  using lower-case is that it is
easier to type.

PS1:4-16                       Berkeley Pascal User's Manual

        :insert
                        until n = 0;
        .
        :$
        end.
        :insert
                end
        .
        :

     At the end of each procedure or function and the end of
the  program  the  translator summarizes references to unde-
fined 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  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 sin, so we can
correct this expression, and translate the program. We  have
now  made  a correction for each diagnosed error in our pro-
gram.

        :?i ?s//c /
                        y := exp(-x) * sin(c * x);
        :write
        "bigger.p" 26 lines, 538 characters
        :quit
        % pi bigger.p
        %

It should be noted that the  translator  suppresses  warning
diagnostics for a particular procedure, function or the main
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.

     We are now ready to execute our program for  the  first
time. We will do so in the next section after giving a list-
ing of the corrected program for reference purposes.

        % cat -n bigger.p
        Insert output of bigger6.p here.
        %

2.4. Executing the second example

     We are now ready to execute  the  second  example.  The

Berkeley Pascal User's Manual                       PS1:4-17

following output was produced by our first run.

        % px
        Insert output of bigout2 here.
        %

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:

        % ex bigger.p
        "bigger.p" 26 lines, 538 characters
        :17
                x := d / i
        :s'/'*
                x := d * i
        :write
        "bigger.p" 26 lines, 538 characters
        :q
        % pix bigger.p
        Insert output of bigout3 here.
        %

     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:

        % px > graph

We can use 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.

        % px | lpr
        Insert output of bigout4 here.
        %

Note here that the statistics lines came out on  our  termi-
nal.  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.:

        % px |& lpr
        %

PS1:4-18                       Berkeley Pascal User's Manual

or we can translate the program with the p  option  disabled
on  the  command line as we did above. This will disable all
post-mortem dumping including the statistics line, thus:

        % pi -p bigger.p
        % px | lpr
        %

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  p  is  specified  and  an
error  occurs, you will not get run time diagnostic informa-
tion to help you determine what the problem is.

2.5. Formatting the program listing

     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 sec-
tion 5.2 for details on the n and i options of pi.

2.6. Execution profiling

     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.

An example

     A prime number is a number which is divisible  only  by
itself  and  the  number one. The program primes, written by
Niklaus Wirth, determines the first few  prime  numbers.  In
translating  the  program  we have specified the z option to
pix. 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.+
_________________________
+The counts are completely accurate only in the absence

Berkeley Pascal User's Manual                       PS1:4-19

When execution of the program completes, either normally  or
abnormally,  this count data is written to the file pmon.out
in the current directory.* It is then possible to prepare an
execution profile by giving pxp the name of the file associ-
ated with this data, as was done in the following example.

        % pix -l -z primes.p
        Insert output of primeout1 here.
        %

Discussion

     The header lines of the outputs of pix and pxp 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 version stamp the input
program. Pxp also indicates the time at  which  the  profile
data was gathered.

        % pxp -z primes.p
        Insert output of primeout2 here.
        %

     To determine the number of times a statement  was  exe-
cuted,  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, k was incremented
157 times on line 18, while the write procedure call on line
24  was  executed  48  times  as  given  by the count on the
repeat.

_________________________
of runtime errors and nonlocal goto statements. This is
not generally a problem, however, as in structured pro-
grams  nonlocal goto statements occur infrequently, and
counts are incorrect after  abnormal  termination  only
when  the  upward  look  described below to get a count
passes a suspended call point.
*Pmon.out has a name similar  to  mon.out  the  monitor
file  produced  by the profiling facility of the C com-
piler cc (1). See prof (1) for a discussion  of  the  C
compiler profiling facilities.

PS1:4-20                       Berkeley Pascal User's Manual

     More information on pxp can be found in its manual sec-
tion pxp (1) and in sections 5.4, 5.5 and 5.10.

3. Error diagnostics

     This section of the User's Manual discusses  the  error
diagnostics  of  the programs pi, pc and px. Pix is a simple
but useful program which invokes pi and px  to  do  all  the
real  processing. See its manual section pix (1) and section
5.2 below for more details. All the diagnostics given by  pi
will also be given by pc.

3.1. Translator syntax errors

     A few comments on the  general  nature  of  the  syntax
errors  usually  made by Pascal programmers and the recovery
mechanisms of the current translator may help in  using  the
system.

Illegal characters

     Characters such as `$', `!', and `@' are  not  part  of
the  language  Pascal.  If they are found in the source pro-
gram, and are not part of  a  constant  string,  a  constant
character,  or a comment, they are considered to be `illegal
characters'. This can happen if you  leave  off  an  opening
string quote `''. Note that the character `"', although used
in English to quote strings, is not used to quote strings in
Pascal.  Most non-printing characters in your input are also
illegal except in character constants and character strings.
Except  for the tab and form feed characters, which are used
to ease formatting of the program,  non-printing  characters
in  the  input  file print as the character `?' so that they
will show in your listing.

String errors

     There is no character string of  length  0  in  Pascal.
Consequently  the  input  `''' is not acceptable. Similarly,
encountering an end-of-line after an  opening  string  quote
`''  without  encountering the matching closing quote yields
the diagnostic ``Unmatched ' for string''. It is permissible
to use the character `#' instead of `'' to delimit character
and constant strings for portability reasons. For this  rea-
son, a spuriously placed `#' sometimes causes the diagnostic
about unbalanced quotes. Similarly, a `#' in column  one  is
used  when preparing programs which are to be kept in multi-
ple files. See section 5.11 for details.

Comments in a comment, non-terminated comments

     As we saw above, these errors  are  usually  caused  by
leaving  off  a  comment delimiter. You can convert parts of

Berkeley Pascal User's Manual                       PS1:4-21

your program to comments without generating this  diagnostic
since there are two different kinds of comments - those del-
imited by `{' and `}', and those delimited by `(*' and `*)'.
Thus consider:

        { This is a comment enclosing a piece of program
        a := functioncall;      (* comment within comment *)
        procedurecall;
        lhs := rhs;             (* another comment *)
        }

     By using one kind of comment exclusively in  your  pro-
gram  you  can  use  the  other  delimiters when you need to
``comment out'' parts of your program+. In this way you will
also  allow  the  translator to help by detecting statements
accidentally placed within comments.

     If a comment does not terminate before the end  of  the
input  file,  the  translator will point to the beginning of
the comment, indicating that the comment is not  terminated.
In  this case processing will terminate immediately. See the
discussion of ``QUIT'' below.

Digits in numbers

     This part of the language is a minor  nuisance.  Pascal
requires  digits  in  real numbers both before and after the
decimal point. Thus the  following  statements,  which  look
quite  reasonable  to FORTRAN users, generate diagnostics in
Pascal:

        Insert output of digitsout here.

These same constructs are also illegal as input to the  Pas-
cal interpreter px.

Replacements, insertions, and deletions

     When a syntax error is encountered in the  input  text,
the  parser  invokes  an error recovery procedure. This pro-
cedure examines the input text immediately after  the  point
of  error  and  considers a set of simple corrections to see
_________________________
+If you wish to transport your program,  especially  to
the 6000-3.4 implementation, you should use the charac-
ter sequence `(*' to delimit comments. For  transporta-
tion over the rcslink to Pascal 6000-3.4, the character
`#' should be used to delimit characters  and  constant
strings.

PS1:4-22                       Berkeley Pascal User's Manual

whether they will allow  the  analysis  to  continue.  These
corrections  involve  replacing  an  input token with a dif-
ferent token, inserting a token, or replacing an input token
with a different token. Most of these changes will not cause
fatal syntax errors. The exception is the  insertion  of  or
replacement with a symbol such as an identifier or a number;
in this case the recovery  makes  no  attempt  to  determine
which  identifier  or  what number should be inserted, hence
these are considered fatal syntax errors.

     Consider the following example.

        % pix -l synerr.p
        Insert output of synerrout here.
        %

The only surprise here may be that Pascal does not  have  an
exponentiation  operator,  hence  the  complaint about `**'.
This error illustrates that, if you assume that the language
has  a  feature which it does not, the translator diagnostic
may not indicate this, as  the  translator  is  unlikely  to
recognize the construct you supply.

Undefined or improper identifiers

     If an identifier is encountered in  the  input  but  is
undefined,  the error recovery will replace it with an iden-
tifier of the appropriate class. Further references to  this
identifier  will  be summarized at the end of the containing
procedure or function or at the end of the  program  if  the
reference  occurred  in  the  main program. Similarly, if an
identifier is used in an inappropriate way, e.g. if  a  type
identifier  is used in an assignment statement, or if a sim-
ple variable is used where a record variable is required,  a
diagnostic  will  be  produced  and  an  identifier  of  the
appropriate type inserted. Further incorrect  references  to
this  identifier  will  be  flagged  only  if  they  involve
incorrect use in a different way, with  all  incorrect  uses
being  summarized in the same way as undefined variable uses
are.

Expected symbols, malformed constructs

     If none of the above mentioned corrections appear  rea-
sonable,  the  error  recovery will examine the input to the
left of the point of error to see if there is only one  sym-
bol  which  can  follow this input. If this is the case, the
recovery will print a diagnostic which  indicates  that  the
given symbol was `Expected'.

     In cases where none of these  corrections  resolve  the
problems  in  the input, the recovery may issue a diagnostic

Berkeley Pascal User's Manual                       PS1:4-23

that indicates that the input is  ``malformed''.  If  neces-
sary, the translator may then skip forward in the input to a
place where analysis can continue. This  process  may  cause
some errors in the text to be missed.

     Consider the following example:

        % pix -l synerr2.p
        Insert output of synerr2out here.
        %

Here we misspelled output and gave a FORTRAN style  variable
declaration  which  the translator diagnosed as a `Malformed
declaration'. When, on line 6, we used `(' and `)' for  sub-
scripting  (as in FORTRAN) rather than the `[' and `]' which
are used in Pascal, the translator  noted  that  a  was  not
defined  as a procedure. This occurred because procedure and
function argument lists are delimited by parentheses in Pas-
cal.  As  it is not permissible to assign to procedure calls
the translator diagnosed a malformed statement at the  point
of assignment.

Expected and unexpected end-of-file, ``QUIT''

     If the translator finds a complete program,  but  there
is  more  non-comment  text  in the input file, then it will
indicate that an end-of-file was  expected.  This  situation
may  occur after a bracketing error, or if too many ends are
present in the input.  The  message  may  appear  after  the
recovery says that it ``Expected `.''' since `.' is the sym-
bol that terminates a program.

     If severe errors in the input prohibit further process-
ing  the  translator  may  produce  a diagnostic followed by
``QUIT''. One example of this  was  given  above  -  a  non-
terminated  comment;  another  example  is  a  line which is
longer than 160  characters.  Consider  also  the  following
example.

        % pix -l mism.p
        Insert output of mismout here.
        %

3.2. Translator semantic errors

     The extremely large number of semantic diagnostic  mes-
sages  which the translator produces make it unreasonable to
discuss each message or group of  messages  in  detail.  The
messages  are,  however,  very  informative.  We  will  here
explain the typical formats and the terminology used in  the

PS1:4-24                       Berkeley Pascal User's Manual

error messages so that you will be able to make sense out of
them. In any case in which a diagnostic  is  not  completely
comprehensible  you  can  refer to the User Manual by Jensen
and Wirth for examples.

Format of the error diagnostics

     As we saw in the example program above, the error diag-
nostics  from  the Pascal translator include the number of a
line in the text of the program as well as the text  of  the
error  message.  While  this  number  is most often the line
where the error occurred, it is occasionally the number of a
line  containing  a bracketing keyword like end or until. In
this case, the diagnostic may refer to the  previous  state-
ment.  This occurs because of the method the translator uses
for sampling line numbers. The absence of a trailing `;'  in
the  previous statement causes the line number corresponding
to the end or until. to become associated  with  the  state-
ment.  As  Pascal is a free-format language, the line number
associations can only be approximate and may seem  arbitrary
to  some users. This is the only notable exception, however,
to reasonable associations.

Incompatible types

     Since Pascal is a strongly typed language, many  seman-
tic  errors  manifest  themselves  as type errors. These are
called `type clashes' by the translator. The  types  allowed
for various operators in the language are summarized on page
108 of the Jensen-Wirth User Manual. It is important to know
that  the  Pascal  translator,  in  its diagnostics, distin-
guishes between the following type `classes':

array        Boolean      char         file         integer
pointer      real         record       scalar       string

These words are plugged into a great number  of  error  mes-
sages.  Thus,  if  you tried to assign an integer value to a
char variable you would receive a diagnostic like  the  fol-
lowing:

        Insert output of clashout here.

In this case, one error produced a two line  error  message.
If  the  same error occurs more than once, the same explana-
tory diagnostic will be given each time.

Scalar

     The only class whose meaning is not self-explanatory is
`scalar'.  Scalar  has a precise meaning in the Jensen-Wirth
User Manual where, in fact,  it  refers  to  char,  integer,

Berkeley Pascal User's Manual                       PS1:4-25

real, and Boolean types as well as the enumerated types. For
the purposes of the Pascal translator, scalar  in  an  error
message  refers  to a user-defined, enumerated type, such as
ops in the example above or color in

        type color = (red, green, blue)

For integers, the more explicit denotation integer is  used.
Although  it  would  be  correct, in the context of the User
Manual to refer to an integer variable as a scalar  variable
pi prefers the more specific identification.

Function and procedure type errors

     For built-in procedures and  functions,  two  kinds  of
errors  occur.  If  the  routines  are called with the wrong
number of arguments a message similar to:

        Insert output of sinout1 here.

is given. If the type of the argument is  wrong,  a  message
like

        Insert output of sinout2 here.

is produced. A few functions and procedures  implemented  in
Pascal  6000-3.4  are diagnosed as unimplemented in Berkeley
Pascal, notably those related to segmented files.

Can't read and write scalars, etc.

     The messages which  state  that  scalar  (user-defined)
types cannot be written to and from files are often mysteri-
ous. It is in fact the case that if you define

        type color = (red, green, blue)

``standard'' Pascal does not associate these constants  with
the strings `red', `green', and `blue' in any way. An exten-
sion has been added which allows enumerated types to be read
and  written,  however if the program is to be portable, you
will have to write your own routines to perform these  func-
tions.  Standard  Pascal  only allows the reading of charac-
ters, integers and real numbers from text files. You  cannot
read strings or Booleans. It is possible to make a

        file of color

PS1:4-26                       Berkeley Pascal User's Manual

but the representation is binary rather than string.

Expression diagnostics

     The diagnostics for semantically ill-formed expressions
are very explicit. Consider this sample translation:

        % pi -l expr.p
        Insert output of exprout here.
        %

This example is admittedly far-fetched, but illustrates that
the  error  messages  are  sufficiently  clear to allow easy
determination of the problem in the expressions.

Type equivalence

     Several diagnostics produced by the  Pascal  translator
complain  about `non-equivalent types'. In general, Berkeley
Pascal considers variables to have the  same  type  only  if
they  were  declared  with the same constructed type or with
the same type  identifier.  Thus,  the  variables  x  and  y
declared as

        var
            x: ^ integer;
            y: ^ integer;

do not have the same type. The assignment

        x := y

thus produces the diagnostics:

        Insert output of typequout here.

Thus it is always necessary to declare a type such as

        type intptr = ^ integer;

and use it to declare

        var x: intptr; y: intptr;

Note that if we had initially declared

Berkeley Pascal User's Manual                       PS1:4-27

        var x, y: ^ integer;

then the assignment statement would have worked. The  state-
ment

        x^ := y^

is allowed in either case. Since the  parameter  to  a  pro-
cedure  or  function must be declared with a type identifier
rather than a constructed type, it is always  necessary,  in
practice,  to  declare  any  type which will be used in this
way.

Unreachable statements

     Berkeley  Pascal  flags  unreachable  statements.  Such
statements  usually  correspond  to  errors  in  the program
logic. Note that a statement is considered to  be  reachable
if  there  is  a  potential  path of control, even if it can
never be taken. Thus, no  diagnostic  is  produced  for  the
statement:

        if false then
            writeln('impossible!')

Goto's into structured statements

     The translator detects and complains about goto  state-
ments  which  transfer  control  into  structured statements
(for, while, etc.) It does not allow such jumps, nor does it
allow  branching  from the then part of an if statement into
the else part. Such checks are made only within the body  of
a single procedure or function.

Unused variables, never set variables

     Although pi always clears variables to 0  at  procedure
and  function  entry, pc does not unless runtime checking is
enabled using the C option. It is not good programming prac-
tice  to  rely  on  this  initialization. To discourage this
practice, and to help detect errors  in  program  logic,  pi
flags as a `w' warning error:

     1)   Use of a variable which is never assigned a value.

     2)   A variable which is declared but never used,  dis-
          tinguishing  between  those  variables  for  which
          values are computed but which are never used,  and
          those completely unused.

PS1:4-28                       Berkeley Pascal User's Manual

In fact, these  diagnostics  are  applied  to  all  declared
items.  Thus  a  const  or a procedure which is declared but
never used is flagged. The w option of pi  may  be  used  to
suppress these warnings; see sections 5.1 and 5.2.

3.3. Translator panics, i/o errors

Panics

     One class of  error  which  rarely  occurs,  but  which
causes  termination  of  all  processing  when  it does is a
panic. A  panic  indicates  a  translator-detected  internal
inconsistency. A typical panic message is:

        snark (rvalue) line=110 yyline=109
        Snark in pi

If you receive such  a  message,  the  translation  will  be
quickly and perhaps ungracefully terminated. You should con-
tact a teaching assistant or a member of the  system  staff,
after saving a copy of your program for later inspection. If
you were making changes to  an  existing  program  when  the
problem occurred, you may be able to work around the problem
by ascertaining which change caused the snark and  making  a
different  change  or  correcting an error in the program. A
small number of panics are possible in px. All panics should
be reported to a teaching assistant or systems staff so that
they can be fixed.

Out of memory

     The only other error which will abort translation  when
no  errors are detected is running out of memory. All tables
in the translator, with the exception of  the  parse  stack,
are  dynamically allocated, and can grow to take up the full
available process space of 64000 bytes on  the  PDP-11.   On
the  VAX-11,  table  sizes  are  extremely generous and very
large (25000) line programs have been  easily  accommodated.
For  the  PDP-11,  it is generally true that the size of the
largest translatable program is  directly  related  to  pro-
cedure  and  function  size.  A number of non-trivial Pascal
programs, including some with more than 2000 lines and  2500
statements have been translated and interpreted using Berke-
ley Pascal on PDP-11's. Notable among these are the Pascal-S
interpreter,  a  large set of programs for automated genera-
tion of code generators, and a general context-free  parsing
program  which has been used to parse sentences with a gram-
mar for a superset of English. In general, very  large  pro-
grams  should be translated using pc and the separate compi-
lation facility.

     If you  receive  an  out  of  space  message  from  the

Berkeley Pascal User's Manual                       PS1:4-29

translator  during translation of a large procedure or func-
tion or one containing a large number  of  string  constants
you  may  yet be able to translate your program if you break
this one procedure or function into several routines.

I/O errors

     Other errors which you may encounter  when  running  pi
relate  to  input-output.  If  pi  cannot  open the file you
specify, or if the file is empty, you will be so informed.

3.4. Run-time errors

     We saw, in our second example,  a  run-time  error.  We
here  give  the  general description of run-time errors. The
more  unusual  interpreter  error  messages  are   explained
briefly in the manual section for px (1).

Start-up errors

     These errors occur when the object file to be  executed
is  not  available  or  appropriate. Typical errors here are
caused by the specified object file not existing, not  being
a Pascal object, or being inaccessible to the user.

Program execution errors

     These errors occur when the program interacts with  the
Pascal  runtime environment in an inappropriate way. Typical
errors are values or subscripts out of range, bad  arguments
to built-in functions, exceeding the statement limit because
of an infinite loop, or running out of memory*.  The  inter-
preter  will  produce  a  backtrace  after the error occurs,
showing all the active routine calls, unless  the  p  option
was disabled when the program was translated. Unfortunately,
no variable values are given and no way of  extracting  them
is available.*

     As an example of such an error,  assume  that  we  have
accidentally  declared the constant n1 to be 6, instead of 7
on line 2 of the program primes  as  given  in  section  2.6
above. If we run this program we get the following response.

_________________________
*The checks for running out of memory are not foolproof
and  there is a chance that the interpreter will fault,
producing a core image when it runs out of memory. This
situation occurs very rarely.
*  On  the VAX-11, each variable is restricted to allo-
cate at most 65000 bytes of storage  (this  is  a  PDP-
11ism that has survived to the VAX.)

PS1:4-30                       Berkeley Pascal User's Manual

        % pix primes.p
        Insert output of primeout3 here.
        %

     Here the interpreter indicates that  the  program  ter-
minated abnormally due to a subscript out of range near line
14, which is eight  lines  into  the  body  of  the  program
primes.

Interrupts

     If the program is interrupted while executing and the p
option was not specified, then a backtrace will be printed.+
The  file pmon.out of profile information will be written if
the program was translated with the z option enabled  to  pi
or pix.

I/O interaction errors

     The final class  of  interpreter  errors  results  from
inappropriate  interactions with files, including the user's
terminal. Included here are bad formats for integer and real
numbers  (such  as  no  digits after the decimal point) when
reading.

4. Input/output

     This  section  describes   features   of   the   Pascal
input/output  environment, with special consideration of the
features peculiar to an interactive implementation.

4.1. Introduction

     Our first sample programs, in section 2, used the  file
output.  We gave examples there of redirecting the output to
a file and to the line printer using the  shell.  Similarly,
we  can  read the input from a file or another program. Con-
sider the following Pascal program which is similar  to  the
program cat (1).

        % pix -l kat.p <primes
        Insert output of katout here.
        %
_________________________
+Occasionally, the Pascal system will be in  an  incon-
sistent  state when this occurs, e.g. when an interrupt
terminates a procedure or function entry  or  exit.  In
this  case, the backtrace will only contain the current
line. A reverse call order list of procedures will  not
be given.

Berkeley Pascal User's Manual                       PS1:4-31

Here we have used the shell's syntax to redirect the program
input  from a file in primes in which we had placed the out-
put of our prime number program of section 2.6. It  is  also
possible  to  `pipe'  input to this program much as we piped
input to the line printer daemon lpr (1) before.  Thus,  the
same output as above would be produced by

        % cat primes | pix -l kat.p

     All of these examples use  the  shell  to  control  the
input  and output from files. One very simple way to associ-
ate Pascal files with named UNIX files is to place the  file
name  in the program statement. For example, suppose we have
previously created the file data. We then use it as input to
another version of a listing program.

        % cat data
        line one.
        line two.
        line three is the end.
        % pix -l copydata.p
        Insert output of copydataout here.
        %

By mentioning the file data in  the  program  statement,  we
have  indicated  that  we  wish it to correspond to the UNIX
file data. Then, when we `reset(data)',  the  Pascal  system
opens  our  file `data' for reading. More sophisticated, but
less portable, examples of using UNIX files will be given in
sections  4.5  and  4.6. There is a portability problem even
with this simple example. Some Pascal systems attach meaning
to  the  ordering  of the file in the program statement file
list. Berkeley Pascal does not do so.

4.2. Eof and eoln

     An extremely common problem encountered by new users of
Pascal, especially in the interactive environment offered by
UNIX, relates to the definitions  of  eof  and  eoln.  These
functions  are  supposed  to  be defined at the beginning of
execution of a Pascal program, indicating whether the  input
device is at the end of a line or the end of a file. Setting
eof or eoln actually corresponds  to  an  implicit  read  in
which  the  input is inspected, but no input is ``used up''.
In fact, there is no way the system  can  know  whether  the
input  is  at  the  end-of-file or the end-of-line unless it
attempts to read a line from it. If the input is from a pre-
viously  created  file,  then  this  reading  can take place
without run-time action by the user. However, if  the  input
is  from a terminal, then the input is what the user types.+

PS1:4-32                       Berkeley Pascal User's Manual

If the system were to do an initial  read  automatically  at
the  beginning of program execution, and if the input were a
terminal, the user would have to type some input before exe-
cution could begin. This would make it  impossible  for  the
program  to  begin  by  prompting  for  input  or printing a
herald.

     Berkeley Pascal has been designed so  that  an  initial
read  is not necessary. At any given time, the Pascal system
may or may not know whether the end-of-file  or  end-of-line
conditions  are  true. Thus, internally, these functions can
have three values - true, false, and ``I don't know yet;  if
you ask me I'll have to find out''. All files remain in this
last, indeterminate state until the Pascal program  requires
a  value  for  eof  or eoln either explicitly or implicitly,
e.g. in a call to read. The important point to note here  is
that if you force the Pascal system to determine whether the
input is at the end-of-file or the end-of-line, it  will  be
necessary for it to attempt to read from the input.

     Thus consider the following example code

        while not eof do begin
            write('number, please? ');
            read(i);
            writeln('that was a ', i: 2)
        end

At first glance, this may be appear to be a correct  program
for  requesting,  reading  and echoing numbers. Notice, how-
ever, that the while loop asks whether eof  is  true  before
the request is printed. This will force the Pascal system to
decide whether the input is at the end-of-file.  The  Pascal
system  will  give  no messages; it will simply wait for the
user to type a line.  By  producing  the  desired  prompting
before testing eof, the following code avoids this problem:

        write('number, please ?');
        while not eof do begin
            read(i);
            writeln('that was a ', i:2);
            write('number, please ?')
        end

The user must still type a line before  the  while  test  is
_________________________
+It is not possible to determine whether the input is a
terminal,  as the input may appear to be a file but ac-
tually be a pipe, the output  of  a  program  which  is
reading from the terminal.

Berkeley Pascal User's Manual                       PS1:4-33

completed, but the prompt will ask  for  it.  This  example,
however,  is  still  not  correct.  To understand why, it is
first necessary to know, as  we  will  discuss  below,  that
there is a blank character at the end of each line in a Pas-
cal text file. The read procedure, when reading integers  or
real  numbers,  is defined so that, if there are only blanks
left in the file, it will return a zero value  and  set  the
end-of-file  condition.  If,  however,  there  is  a  number
remaining in the file, the end-of-file condition will not be
set  even  if it is the last number, as read never reads the
blanks after the number, and there is always  at  least  one
blank. Thus the modified code will still put out a spurious

        that was a 0

at the end of a session with  it  when  the  end-of-file  is
reached.  The  simplest  way  to correct the problem in this
example is to use the procedure readln instead of read here.
In  general,  unless  we test the end-of-file condition both
before and after calls to read  or  readln,  there  will  be
inputs  for which our program will attempt to read past end-
of-file.

4.3. More about eoln

     To have a good understanding of when eoln will be  true
it  is necessary to know that in any file there is a special
character indicating end-of-line, and that, in  effect,  the
Pascal system always reads one character ahead of the Pascal
read commands.+ For instance, in response to `read(ch)', the
system  sets  ch to the current input character and gets the
next input character. If the current input character is  the
last  character  of  the line, then the next input character
from the file is the new-line  character,  the  normal  UNIX
line  separator.  When  the  read  routine gets the new-line
character, it replaces that character by  a  blank  (causing
every  line to end with a blank) and sets eoln to true. Eoln
will be true as soon as we read the last  character  of  the
line and before we read the blank character corresponding to
the end of line. Thus it is almost always a mistake to write
a program which deals with input in the following way:

        read(ch);
        if eoln then
            Done with line
        else
            Normal processing
_________________________
+In Pascal terms, `read(ch)' corresponds to `ch :=  in-
put^; get(input)'

PS1:4-34                       Berkeley Pascal User's Manual

as this will almost surely have the effect of  ignoring  the
last  character  in the line. The `read(ch)' belongs as part
of the normal processing.

     Given this framework, it is not  hard  to  explain  the
function of a readln call, which is defined as:

        while not eoln do
            get(input);
        get(input);

This advances the file until the blank corresponding to  the
end-of-line  is  the  current input symbol and then discards
this blank. The next  character  available  from  read  will
therefore  be  the  first character of the next line, if one
exists.

4.4. Output buffering

     A final point about Pascal input-output must  be  noted
here.  This concerns the buffering of the file output. It is
extremely inefficient for the Pascal  system  to  send  each
character to the user's terminal as the program generates it
for output; even less efficient if the output is  the  input
of  another program such as the line printer daemon lpr (1).
To gain efficiency, the Pascal system ``buffers'' the output
characters (i.e. it saves them in memory until the buffer is
full and then emits the entire buffer in one system interac-
tion.) However, to allow interactive prompting to work as in
the example given above, this prompt must be printed  before
the  Pascal  system  waits  for a response. For this reason,
Pascal normally prints all the output which  has  been  gen-
erated for the file output whenever

     1)   A writeln occurs, or

     2)   The program reads from the terminal, or

     3)   The procedure message or flush is called.

Thus, in the code sequence

        for i := 1 to 5 do begin
            write(i: 2);
            Compute a lot with no output
        end;
        writeln

the output integers will not print until the writeln occurs.
The  delay  can be somewhat disconcerting, and you should be
aware that it will occur. By  setting  the  b  option  to  0

Berkeley Pascal User's Manual                       PS1:4-35

before  the  program statement by inserting a comment of the
form

        (*$b0*)

we can cause output to  be  completely  unbuffered,  with  a
corresponding  horrendous degradation in program efficiency.
Option control in comments is discussed in section 5.

4.5. Files, reset, and rewrite

     It is possible to use extended forms  of  the  built-in
functions reset and rewrite to get more general associations
of UNIX file names with Pascal file variables. When  a  file
other  than  input  or output is to be read or written, then
the reading or writing  must  be  preceded  by  a  reset  or
rewrite  call.  In  general, if the Pascal file variable has
never been used before, there will be no UNIX filename asso-
ciated  with it. As we saw in section 2.9, by mentioning the
file in the program statement, we could cause  a  UNIX  file
with  the  same name as the Pascal variable to be associated
with it. If we do not mention a file in the  program  state-
ment and use it for the first time with the statement

        reset(f)

or

        rewrite(f)

then the Pascal system will generate a temporary name of the
form `tmp.x' for some character `x', and associate this UNIX
file name name with the Pascal file.  The  first  such  gen-
erated name will be `tmp.1' and the names continue by incre-
menting their last character  through  the  ASCII  set.  The
advantage  of  using  such  temporary files is that they are
automatically removed by the Pascal system as soon  as  they
become  inaccessible.  They  are  not removed, however, if a
runtime error causes termination while they are in scope.

     To cause a particular UNIX pathname  to  be  associated
with  a  Pascal  file  variable we can give that name in the
reset or rewrite call, e.g. we  could  have  associated  the
Pascal  file  data  with the file `primes' in our example in
section 3.1 by doing:

        reset(data, 'primes')

instead of a simple

PS1:4-36                       Berkeley Pascal User's Manual

        reset(data)

In this case it is not essential to mention  `data'  in  the
program  statement,  but  it is still a good idea because is
serves as an aid to program documentation. The second param-
eter to reset and rewrite may be any string value, including
a variable. Thus the names of UNIX files  to  be  associated
with  Pascal file variables can be read in at run time. Full
details on file name/file variable associations are given in
section A.3.

4.6. Argc and argv

     Each UNIX process receives a variable  length  sequence
of  arguments  each  of which is a variable length character
string. The built-in function argc  and  the  built-in  pro-
cedure  argv  can  be used to access and process these argu-
ments. The value of the function argc is the number of argu-
ments  to  the  process.  By  convention,  the arguments are
treated as an array, and indexed from 0 to argc-1, with  the
zeroth  argument  being  the  name of the program being exe-
cuted. The rest of the arguments are  those  passed  to  the
command on the command line. Thus, the command

        % obj  /etc/motd  /usr/dict/words hello

will invoke the program in the file obj with argc  having  a
value  of  4.  The  zeroth  element accessed by argv will be
`obj', the first `/etc/motd', etc.

     Pascal does not provide variable size arrays, nor  does
it  allow character strings of varying length. For this rea-
son, argv is a procedure and has the syntax

        argv(i, a)

where i is an integer and a is a string variable. This  pro-
cedure call assigns the (possibly truncated or blank padded)
i'th argument of the current process to the string  variable
a.  The  file  manipulation  routines reset and rewrite will
strip trailing blanks from their optional  second  arguments
so  that  this  blank  padding is not a problem in the usual
case where the arguments are file names.

     We are now ready to  give  a  Berkeley  Pascal  program
`kat',  based  on that given in section 3.1 above, which can
be used with the same syntax as the UNIX system program  cat
(1).

        % cat kat.p

Berkeley Pascal User's Manual                       PS1:4-37

        program kat(input, output);
        var
            ch: char;
            i: integer;
            name: packed array [1..100] of char;
        begin
            i := 1;
            repeat
                if i < argc then begin
                    argv(i, name);
                    reset(input, name);
                    i := i + 1
                end;
                while not eof do begin
                    while not eoln do begin
                        read(ch);
                        write(ch)
                    end;
                    readln;
                    writeln
                end
            until i >= argc
        end { kat }.
        %

Note that the reset call to the file input  here,  which  is
necessary  for  a  clear program, may be disallowed on other
systems. As this program deals mostly with argc and argv and
UNIX system dependent considerations, portability is of lit-
tle concern.

     If this program is in the file `kat.p', then we can do

        % pi kat.p
        % mv obj kat
        % kat primes
        Insert output of kat2out here.
        % kat
        Insert output of katscript here.
        %

Thus we see that, if it is given arguments, `kat' will, like
cat,  copy  each  one in turn. If no arguments are given, it
copies from the standard input. Thus it will work as it  did
before, with

        % kat < primes

now equivalent to

PS1:4-38                       Berkeley Pascal User's Manual

        % kat primes

although the mechanisms  are  quite  different  in  the  two
cases.  Note  that  if  `kat'  is given a bad file name, for
example:

        % kat xxxxqqq
        Insert output of xxxxqqqout here.
        %

it will give a diagnostic and  a  post-mortem  control  flow
backtrace  for  debugging. If we were going to use `kat', we
might want to translate it differently, e.g.:

        % pi -pb kat.p
        % mv obj kat

Here we have disabled the post-mortem  statistics  printing,
so  as  not  to  get the statistics or the full traceback on
error. The b option will cause the system  to  block  buffer
the  input/output  so  that  the program will run more effi-
ciently on large files. We could have also specified  the  t
option  to  turn  off runtime tests if that was felt to be a
speed hindrance to the program. Thus we  can  try  the  last
examples again:

        % kat xxxxqqq
        Insert output of xxxxqqqout2 here.
        % kat primes
        Insert output of primes-d here.
        %

     The interested reader may wish to try writing a program
which  accepts  command  line  arguments like pi does, using
argc and argv to process them.

5. Details on the components of the system

5.1. Options

     The programs pi, pc, and pxp take a number of options.+
There  is  a standard UNIX convention for passing options to
programs on the command line, and this  convention  is  fol-
lowed  by  the Berkeley Pascal system programs. As we saw in
_________________________
+As pix uses pi to translate Pascal programs, it  takes
the options of pi also. We refer to them here, however,
as pi options.

Berkeley Pascal User's Manual                       PS1:4-39

the examples above, option related  arguments  consisted  of
the  character  `-'  followed  by  a single character option
name.

     Except for the b option  which  takes  a  single  digit
value,  each  option  may  be  set on (enabled) or off (dis-
abled.) When an on/off valued option appears on the  command
line of pi or it inverts the default setting of that option.
Thus

        % pi -l foo.p

enables the listing option l, since it defaults off, while

        % pi -t foo.p

disables the run time tests option t, since it defaults on.

     In additon to inverting  the  default  settings  of  pi
options  on the command line, it is also possible to control
the pi options within the body of the program by using  com-
ments of a special form illustrated by

        {$l-}

     Here we see that the opening comment  delimiter  (which
could also be a `(*') is immediately followed by the charac-
ter `$'. After this `$', which  signals  the  start  of  the
option  list,  we can place a sequence of letters and option
controls, separated  by  `,'  characters*.  The  most  basic
actions for options are to set them, thus

        {$l+ Enable listing}

or to clear them

        {$t-,p- No run-time tests, no post mortem analysis}
_________________________
*This format was chosen because it is  used  by  Pascal
6000-3.4.  In general the options common to both imple-
mentations are controlled in the same way so that  com-
ment  control  in  options  is  mostly  portable. It is
recommended, however, that only one control be put  per
comment for maximum portability, as the Pascal 6000-3.4
implementation will ignore controls after the first one
which it does not recognize.

PS1:4-40                       Berkeley Pascal User's Manual

Notice that `+' always enables an option and `-' always dis-
ables it, no matter what the default is. Thus `-' has a dif-
ferent meaning in an option comment than it has on the  com-
mand line. As shown in the examples, normal comment text may
follow the option list.

5.2. Options common to Pi, Pc, and Pix

     The following options are common to both  the  compiler
and  the  interpreter.  With each option we give its default
setting, the setting it would have if  it  appeared  on  the
command  line,  and  a sample command using the option. Most
options are on/off valued, with the b option taking a single
digit value.

Buffering of the file output - b

     The b option controls the buffering of the file output.
The  default is line buffering, with flushing at each refer-
ence to the file input and under certain other circumstances
detailed  in  section  5  below. Mentioning b on the command
line, e.g.

        % pi -b assembler.p

causes standard output to be block buffered, where  a  block
is  some  system-defined  number of characters. The b option
may also be controlled in comments.  It,  unique  among  the
Berkeley  Pascal  options, takes a single digit value rather
than an on or off setting. A value of 0, e.g.

                {$b0}

causes the file output to be  unbuffered.  Any  value  2  or
greater causes block buffering and is equivalent to the flag
on the command line. The option control  comment  setting  b
must precede the program statement.

Include file listing - i

     The i option takes the name of an  include  file,  pro-
cedure  or  function  name  and causes it to be listed while
translating+. Typical uses would be

        % pix -i scanner.i compiler.p

to make a listing of the routines in the file scanner.i, and
_________________________
+Include files are discussed in section 5.9.

Berkeley Pascal User's Manual                       PS1:4-41

        % pix -i scanner compiler.p

to make a listing of only the routine scanner.  This  option
is  especially  useful  for  conservation-minded programmers
making partial program listings.

Make a listing - l

     The l option enables a listing of the  program.  The  l
option  defaults off. When specified on the command line, it
causes a header line identifying the version of the transla-
tor  in  use  and a line giving the modification time of the
file being translated to appear before  the  actual  program
listing.  The  l option is pushed and popped by the i option
at appropriate points in the program.

Standard Pascal only - s

     The s option causes many of the features  of  the  UNIX
implementation  which are not found in standard Pascal to be
diagnosed as `s' warning errors. This  option  defaults  off
and  is  enabled when mentioned on the command line. Some of
the  features  which   are   diagnosed   are:   non-standard
procedures and functions, extensions to the procedure write,
and the padding of constant strings with  blanks.  In  addi-
tion, all letters are mapped to lower case except in strings
and characters so that the case of keywords and  identifiers
is  effectively  ignored. The s option is most useful when a
program is to be transported, thus

        % pi -s isitstd.p

will produce warnings unless the program meets the standard.

Runtime tests - t and C

     These options control  the  generation  of  tests  that
subrange  variable  values are within bounds at run time. pi
defaults to generating tests and uses the option t  to  dis-
able them. pc defaults to not generating tests, and uses the
option C to enable them. Disabling runtime tests also causes
assert statements to be treated as comments.*

Suppress warning diagnostics - w

     The w option, which defaults on, allows the  translator
to print a number of warnings about inconsistencies it finds
in the input program. Turning this option off with a comment
_________________________
*See section A.1 for a  description  of  assert  state-
ments.

PS1:4-42                       Berkeley Pascal User's Manual

of the form

        {$w-}

or on the command line

        % pi -w tryme.p

suppresses these usually useful diagnostics.

Generate counters for a pxp execution profile - z

     The z option, which defaults off, enables  the  produc-
tion  of  execution profiles. By specifying z on the command
line, i.e.

        % pi -z foo.p

or by enabling it in a comment before the program  statement
causes  pi  and  pc  to insert operations in the interpreter
code to count the number of times each  statement  was  exe-
cuted. An example of using pxp was given in section 2.6; its
options are described in section 5.6. Note that the z option
cannot be used on separately compiled programs.

5.3. Options available in Pi

Post-mortem dump - p

     The p option defaults on, and causes the runtime system
to initiate a post-mortem backtrace when an error occurs. It
also cause px to count statements in the executing  program,
enforcing  a  statement  limit  to  prevent  infinite loops.
Specifying p on the command line disables these  checks  and
the  ability to give this post-mortem analysis. It does make
smaller and faster programs, however. It is also possible to
control the p option in comments. To prevent the post-mortem
backtrace on error, p must be off at the end of the  program
statement.  Thus,  the  Pascal  cross-reference  program was
translated with

        % pi -pbt pxref.p

5.4. Options available in Px

     The first argument to px is the name of the  file  con-
taining  the  program to be interpreted. If no arguments are
given, then the file obj is executed. If more arguments  are

Berkeley Pascal User's Manual                       PS1:4-43

given, they are available to the Pascal program by using the
built-ins argc and argv as described in section 4.6.

     Px may also be invoked  automatically.  In  this  case,
whenever  a  Pascal  object file name is given as a command,
the command will be executed with px prepended to  it;  that
is

        % obj primes

will be converted to read

        % px obj primes

5.5. Options available in Pc

Generate assembly language - S

     The program is compiled and the assembly language  out-
put is left in file appended .s. Thus

        % pc -S foo.p

creates a file foo.s. No executable file is created.

Symbolic Debugger Information - g

     The g option causes the compiler to  generate  informa-
tion  needed by sdb(1) the symbolic debugger. For a complete
description of sdb see  Volume  2c  of  the  UNIX  Reference
Manual.

Redirect the output file - o

     The name argument after the -o is used as the  name  of
the output file instead of a.out. Its typical use is to name
the compiled program using the root of the file name. Thus:

        % pc -o myprog myprog.p

causes the compiled program to be called myprog.

Generate counters for a prof execution profile - p

     The compiler produces code which counts the  number  of
times  each  routine  is called. The profiling is based on a
periodic sample taken by the system rather  than  by  inline
counters  used  by  pxp. This results in less degradation in

PS1:4-44                       Berkeley Pascal User's Manual

execution, at somewhat of a loss in  accuracy.  See  prof(1)
for a more complete description.

Run the object code optimizer - O

     The output of the compiler is run  through  the  object
code optimizer. This provides an increase in compile time in
exchange for a decrease in compiled code size and  execution
time.

5.6. Options available in Pxp

     Pxp takes, on its command line, a list of options  fol-
lowed by the program file name, which must end in `.p' as it
must for pi, pc, and pix. Pxp will produce an execution pro-
file  if  any  of  the z, t or c options is specified on the
command line. If none of these options  is  specified,  then
pxp functions as a program reformatter.

     It is important to note that only the z and  w  options
of  pxp,  which  are  common  to pi, pc, and pxp can be con-
trolled in comments. All other options must be specified  on
the command line to have any effect.

     The following options are relevant  to  profiling  with
pxp:

Include the bodies of all routines in the profile - a

     Pxp normally suppresses printing the bodies of routines
which were never executed, to make the profile more compact.
This option forces all routine bodies to be printed.

Suppress declaration parts from a profile - d

     Normally a profile includes declaration parts. Specify-
ing d on the command line suppresses declaration parts.

Eliminate include directives - e

     Normally, pxp preserves include directives to the  out-
put  when  reformatting  a program, as though they were com-
ments. Specifying -e causes the contents  of  the  specified
files to be reformatted into the output stream instead. This
is an easy way to eliminate include directives, e.g.  before
transporting a program.

Fully parenthesize expressions - f

     Normally  pxp  prints  expressions  with  the   minimal
parenthesization  necessary to preserve the structure of the
input. This option causes pxp to fully parenthesize  expres-
sions. Thus the statement which prints as

Berkeley Pascal User's Manual                       PS1:4-45

        d := a + b mod c / e

with minimal parenthesization, the default, will print as

        d := a + ((b mod c) / e)

with the f option specified on the command line.

Left justify all procedures and functions - j

     Normally, each procedure and function body is  indented
to  reflect  its  static nesting depth. This option prevents
this nesting and can be used if the indented output would be
too wide.

Print a table summarizing procedure and function calls - t

     The t option causes pxp to print  a  table  summarizing
the  number  of  calls to each procedure and function in the
program. It may be  specified  in  combination  with  the  z
option, or separately.

Enable and control the profile - z

     The z profile option is very similar to the  i  listing
control option of pi. If z is specified on the command line,
then all arguments up to the source file argument which ends
in  `.p'  are  taken  to  be  the  names  of  procedures and
functions or include files which are to be profiled. If this
list is null, then the whole file is to be profiled. A typi-
cal command for extracting a profile of part of a large pro-
gram would be

        % pxp -z test parser.i compiler.p

This specifies that profiles of the  routines  in  the  file
parser.i and the routine test are to be made.

5.7. Formatting programs using pxp

     The program pxp can be used to  reformat  programs,  by
using a command of the form

        % pxp dirty.p > clean.p

Note that since the shell creates the output file  `clean.p'
before  pxp executes, so `clean.p' and `dirty.p' must not be
the same file.

     Pxp automatically paragraphs  the  program,  performing

PS1:4-46                       Berkeley Pascal User's Manual

housekeeping  chores such as comment alignment, and treating
blank lines, lines containing exactly one  blank  and  lines
containing  only  a  form-feed character as though they were
comments, preserving their vertical spacing  effect  in  the
output. Pxp distinguishes between four kinds of comments:

     1)   Left marginal comments, which begin in  the  first
          column  of  the  input  line and are placed in the
          first column of an output line.

     2)   Aligned comments, which are preceded by  no  input
          tokens on the input line. These are aligned in the
          output with the running program text.

     3)   Trailing comments, which are preceded in the input
          line  by  a  token  with  no  more than two spaces
          separating the token from the comment.

     4)   Right marginal comments, which are preceded in the
          input   line  by  a  token  from  which  they  are
          separated by at least three spaces or a tab. These
          are  aligned  down the right margin of the output,
          currently to the first tab  stop  after  the  40th
          column from the current ``left margin''.

Consider the following program.

        % cat comments.p
        Insert output of comments1.p here.

When formatted by pxp the following output is produced.

        % pxp comments.p
        Insert output of commentsout here.
        %

The  following  formatting  related  options  are  currently
available  in pxp. The options f and j described in the pre-
vious section may also be of interest.

Strip comments -s

     The s option causes pxp to remove all comments from the
input text.

Underline keywords - _

     A command line argument of the form -_ as in

        % pxp -_ dirty.p

Berkeley Pascal User's Manual                       PS1:4-47

can be used to cause pxp to underline all  keywords  in  the
output for enhanced readability.

Specify indenting unit - [23456789]

     The normal unit which pxp uses to  indent  a  structure
statement  level  is  4 spaces. By giving an argument of the
form -d with d a digit, 2 ≤ d ≤ 9 you  can  specify  that  d
spaces are to be used per level instead.

5.8. Pxref

     The cross-reference program pxref may be used  to  make
cross-referenced  listings  of Pascal programs. To produce a
cross-reference of the program in the file `foo.p'  one  can
execute the command:

        % pxref foo.p

The cross-reference is, unfortunately, not block structured.
Full  details on pxref are given in its manual section pxref
(1).

5.9. Multi-file programs

     A text inclusion facility is  available  with  Berkeley
Pascal.  This  facility  allows  the interpolation of source
text from other files into the source stream of the transla-
tor.  It  can  be  used  to  divide large programs into more
manageable pieces for ease in editing, listing, and  mainte-
nance.

     The include facility is based on that  of  the  UNIX  C
compiler.  To  trigger it you can place the character `#' in
the first portion of a line and  then,  after  an  arbitrary
number  of  blanks or tabs, the word `include' followed by a
filename enclosed in single  `''  or  double  `"'  quotation
marks.  The  file name may be followed by a semicolon `;' if
you wish to treat this as  a  pseudo-Pascal  statement.  The
filenames  of included files must end in `.i'. An example of
the use of included files in a main program would be:

        program compiler(input, output, obj);

        #include "globals.i"
        #include "scanner.i"
        #include "parser.i"
        #include "semantics.i"

        begin
            { main program }

PS1:4-48                       Berkeley Pascal User's Manual

        end.

     At the point the include  pseudo-statement  is  encoun-
tered  in  the  input,  the lines from the included file are
interpolated into the input  stream.  For  the  purposes  of
translation and runtime diagnostics and statement numbers in
the listings and post-mortem backtraces, the  lines  in  the
included  file are numbered from 1. Nested includes are pos-
sible up to 10 deep.

     See the descriptions of the i option of pi  in  section
5.2  above; this can be used to control listing when include
files are present.

     When a non-trivial line is encountered  in  the  source
text  after  an  include  finishes, the `popped' filename is
printed, in the same manner as above.

     For the purposes of error diagnostics when not making a
listing, the filename will be printed before each diagnostic
if the current filename has changed since the last  filename
was printed.

5.10. Separate Compilation with Pc

     A separate compilation facility is  provided  with  the
Berkeley  Pascal compiler, pc. This facility allows programs
to be divided into a number of files and the  pieces  to  be
compiled  individually,  to be linked together at some later
time. This is especially useful for  large  programs,  where
small  changes  would  otherwise  require time-consuming re-
compilation of the entire program.

     Normally, pc expects to be  given  entire  Pascal  pro-
grams.  However, if given the -c option on the command line,
it will accept a sequence of definitions  and  declarations,
and  compile them into a .o file, to be linked with a Pascal
program at a later time. In order that procedures and  func-
tions  be  available  across separately compiled files, they
must be declared with the directive external. This directive
is  similar to the directive forward in that it must precede
the resolution of the  function  or  procedure,  and  formal
parameters  and  function  result types must be specified at
the external declaration and may not  be  specified  at  the
resolution.

     Type checking is performed across  separately  compiled
files. Since Pascal type defintions define unique types, any
types which are shared  between  separately  compiled  files
must be the same definition. This seemingly impossible prob-
lem is solved using a facility similar to the include facil-
ity discussed above. Definitions may be placed in files with

Berkeley Pascal User's Manual                       PS1:4-49

the extension .h and the files included by  separately  com-
piled files. Each definition from a .h file defines a unique
type, and all uses of a definition from  the  same  .h  file
define the same type. Similarly, the facility is extended to
allow the  definition  of  consts  and  the  declaration  of
labels,  vars,  and  external functions and procedures. Thus
procedures and functions which are used  between  separately
compiled  files  must  be  declared external, and must be so
declared in a .h file included by any file  which  calls  or
resolves  the  function  or procedure. Conversely, functions
and procedures declared external may only be so declared  in
.h  files. These files may be included only at the outermost
level, and thus define or declare global objects. Note  that
since only external function and procedure declarations (and
not resolutions) are allowed in .h files, statically  nested
functions and procedures can not be declared external.

     An example of the use of included .h files in a program
would be:

        program compiler(input, output, obj);

        #include "globals.h"
        #include "scanner.h"
        #include "parser.h"
        #include "semantics.h"

        begin
            { main program }
        end.

     This might include in the main program the  definitions
and  declarations  of  all  the global labels, consts, types
vars from the file globals.h, and the external function  and
procedure  declarations  for each of the separately compiled
files for the scanner, parser and semantics. The header file
scanner.h would contain declarations of the form:

        type
            token = record
                { token fields }
            end;

        function scan(var inputfile: text): token;
            external;

PS1:4-50                       Berkeley Pascal User's Manual

Then the scanner might be in a separately compiled file con-
taining:

        #include "globals.h"
        #include "scanner.h"

        function scan;
        begin
            { scanner code }
        end;

which includes the same global definitions and  declarations
and  resolves  the scanner functions and procedures declared
external in the file scanner.h.

A. Appendix to Wirth's Pascal Report

     This section is an appendix to the  definition  of  the
Pascal  language  in Niklaus Wirth's Pascal Report and, with
that Report, precisely defines the Berkeley  implementation.
This  appendix  includes  a  summary  of  extensions  to the
language, gives the ways in which the  undefined  specifica-
tions  were  resolved, gives limitations and restrictions of
the current implementation, and lists  the  added  functions
and  procedures  available.  It  concludes  with  a  list of
differences with  the  commonly  available  Pascal  6000-3.4
implementation,  and  some comments on standard and portable
Pascal.

A.1. Extensions to the language Pascal

     This section defines non-standard  language  constructs
available  in  Berkeley Pascal. The s standard Pascal option
of the translators pi and pc can be  used  to  detect  these
extensions in programs which are to be transported.

String padding

     Berkeley Pascal will pad constant strings  with  blanks
in  expressions and as value parameters to make them as long
as is required. The following is  a  legal  Berkeley  Pascal
program:

        program x(output);
        var z : packed array [ 1 .. 13 ] of char;
        begin
            z := 'red';
            writeln(z)
        end;

The  padded  blanks  are  added  on  the  right.  Thus   the

Berkeley Pascal User's Manual                       PS1:4-51

assignment above is equivalent to:

        z := 'red          '

which is standard Pascal.

Octal constants, octal and hexadecimal write

     Octal constants may be given as  a  sequence  of  octal
digits followed by the character `b' or `B'. The forms

        write(a:n oct)

and

        write(a:n hex)

cause the internal representation  of  expression  a,  which
must  be  Boolean,  character,  integer, pointer, or a user-
defined enumerated type, to be written in octal  or  hexade-
cimal respectively.

Assert statement

     An assert statement causes a Boolean expression  to  be
evaluated  each  time  the  statement is executed. A runtime
error results if any of  the  expressions  evaluates  to  be
false.  The assert statement is treated as a comment if run-
time tests are disabled. The syntax for assert is:

        assert <expr>

Enumerated type input-output

     Enumerated types may be read and written. On output the
string  name associated with the enumerated value is output.
If the value is out of range, a  runtime  error  occurs.  On
input  an  identifier  is  read  and looked up in a table of
names associated with the type  of  the  variable,  and  the
appropriate internal value is assigned to the variable being
read. If the name is not found in the table a runtime  error
occurs.

Structure returning functions

     An extension has been added which allows  functions  to
return  arbitrary  sized structures rather than just scalars
as in the standard.

PS1:4-52                       Berkeley Pascal User's Manual

Separate compilation

     The compiler pc has been  extended  to  allow  separate
compilation  of  programs. Procedures and functions declared
at the global level may be compiled separately. Type  check-
ing of calls to separately compiled routines is performed at
load time to insure that the program  as  a  whole  is  con-
sistent. See section 5.10 for details.

A.2. Resolution of the undefined specifications

File name - file variable associations

     Each Pascal file variable is associated  with  a  named
UNIX file. Except for input and output, which are exceptions
to some of the rules, a name can become  associated  with  a
file in any of three ways:

     1)   If a global Pascal file variable  appears  in  the
          program  statement then it is associated with UNIX
          file of the same name.

     2)   If  a  file  was  reset  or  rewritten  using  the
          extended  two-argument  form  of  reset or rewrite
          then the given name is associated.

     3)   If a file which has never had UNIX name associated
          is  reset  or  rewritten without specifying a name
          via the second argument, then a temporary name  of
          the form `tmp.x' is associated with the file. Tem-
          porary names start with `tmp.1'  and  continue  by
          incrementing  the  last  character  in the USASCII
          ordering. Temporary files  are  removed  automati-
          cally when their scope is exited.

The program statement

     The syntax of the program statement is:

        program <id> ( <file id> { , <file id > } ) ;

The file identifiers (other than input and output)  must  be
declared as variables of file type in the global declaration
part.

The files input and output

     The formal parameters input and output  are  associated
with  the UNIX standard input and output and have a somewhat
special status. The following rules must be noted:

     1)   The  program  heading  must  contains  the  formal

Berkeley Pascal User's Manual                       PS1:4-53

          parameter  output. If input is used, explicitly or
          implicitly, then it must also be declared here.

     2)   Unlike all other files, the Pascal files input and
          output  must  not  be defined in a declaration, as
          their declaration is automatically:

                  var input, output: text

     3)   The procedure reset may be used on  input.  If  no
          UNIX  file  name  has  ever  been  associated with
          input, and no file name is given, then an  attempt
          will  be  made to `rewind' input. If this fails, a
          run time error will occur. Rewrite calls to output
          act as for any other file, except that output ini-
          tially has no associated file. This means  that  a
          simple

                  rewrite(output)

          associates a temporary name with output.

Details for files

     If a file other than input is to be read, then  reading
must  be  initiated  by  a call to the procedure reset which
causes the Pascal system to attempt to open  the  associated
UNIX  file  for reading. If this fails, then a runtime error
occurs. Writing of a file other than  output  must  be  ini-
tiated  by a rewrite call, which causes the Pascal system to
create the associated UNIX file and to then  open  the  file
for writing only.

Buffering

     The buffering for output is determined by the value  of
the  b option at the end of the program statement. If it has
its default value 1, then output is buffered in blocks of up
to  512 characters, flushed whenever a writeln occurs and at
each reference to the file input. If it  has  the  value  0,
output  is  unbuffered.  Any  value of 2 or more gives block
buffering without line  or  input  reference  flushing.  All
other  output  files  are  always  buffered in blocks of 512
characters. All output buffers are flushed  when  the  files
are  closed at scope exit, whenever the procedure message is
called, and can be  flushed  using  the  built-in  procedure
flush.

     An important point for an interactive implementation is
the  definition of `input^'. If input is a teletype, and the

PS1:4-54                       Berkeley Pascal User's Manual

Pascal system reads a character at the beginning  of  execu-
tion  to define `input^', then no prompt could be printed by
the program before the user is required to type some  input.
For this reason, `input^' is not defined by the system until
its definition is needed, reading from a file occurring only
when necessary.

The character set

     Seven bit USASCII is the character set  used  on  UNIX.
The  standard Pascal symbols `and', 'or', 'not', '<=', '>=',
'<>', and the uparrow `^' (for  pointer  qualification)  are
recognized.+ Less portable are the synonyms  tilde  `~'  for
not, `&' for and, and `|' for or.

     Upper and lower case are  considered  to  be  distinct.
Keywords  and built-in procedure and function names are com-
posed of all lower case letters. Thus the  identifiers  GOTO
and GOto are distinct both from each other and from the key-
word goto. The standard type `boolean' is also available  as
`Boolean'.

     Character strings and constants may be delimited by the
character  `''  or by the character `#'; the latter is some-
times convenient when programs are to be  transported.  Note
that  the  `#'  character has special meaning when it is the
first character on a line - see Multi-file programs below.

The standard types

     The standard type integer is conceptually defined as

        type integer = minint .. maxint;

Integer is implemented with 32 bit  twos  complement  arith-
metic. Predefined constants of type integer are:

        const maxint = 2147483647; minint = -2147483648;

     The standard type char is conceptually defined as

_________________________
+On many  terminals  and  printers,  the  up  arrow  is
represented as a circumflex `^'. These are not distinct
characters, but rather  different  graphic  representa-
tions of the same internal codes.
The proposed standard for Pascal considers them  to  be
the same.

Berkeley Pascal User's Manual                       PS1:4-55

        type char = minchar .. maxchar;

Built-in character constants are  `minchar'  and  `maxchar',
`bell' and `tab'; ord(minchar) = 0, ord(maxchar) = 127.

     The type real is  implemented  using  64  bit  floating
point  arithmetic.  The floating point arithmetic is done in
`rounded' mode, and provides approximately 17 digits of pre-
cision  with  numbers  as  small  as 10 to the negative 38th
power and as large as 10 to the 38th power.

Comments

     Comments can be delimited by either `{' and `}'  or  by
`(*'  and  `*)'.  If  the character `{' appears in a comment
delimited by `{' and `}', a warning diagnostic is printed. A
similar warning will be printed if the sequence `(*' appears
in a comment delimited by `(*'  and  `*)'.  The  restriction
implied  by this warning is not part of standard Pascal, but
detects many otherwise subtle errors.

Option control

     Options of the translators may  be  controlled  in  two
distinct ways. A number of options may appear on the command
line invoking the translator. These options are given as one
or more strings of letters preceded by the character `-' and
cause the  default  setting  of  each  given  option  to  be
changed. This method of communication of options is expected
to predominate for UNIX. Thus the command

        % pi -l -s foo.p

translates the file foo.p with the  listing  option  enabled
(as  it  normally  is  off),  and  with only standard Pascal
features available.

     If more control over the portions of the program  where
options are enabled is required, then option control in com-
ments can and should be used. The format for option  control
in  comments  is  identical to that used in Pascal 6000-3.4.
One places the character `$' as the first character  of  the
comment  and  follows it by a comma separated list of direc-
tives. Thus an equivalent to the command line example  given
above would be:

        {$l+,s+ listing on, standard Pascal}

as the first line of the program. The  `l'  option  is  more
appropriately  specified  on  the  command line, since it is
extremely unlikely in an interactive  environment  that  one

PS1:4-56                       Berkeley Pascal User's Manual

wants a listing of the program each time it is translated.

     Directives consist of a letter designating the  option,
followed  either by a `+' to turn the option on, or by a `-'
to turn the option off. The b option takes  a  single  digit
instead of a `+' or `-'.

Notes on the listings

     The first page of a  listing  includes  a  banner  line
indicating  the  version and date of generation of pi or pc.
It also includes the UNIX path name supplied for the  source
file and the date of last modification of that file.

     Within the body of the listing, lines are numbered con-
secutively  and  correspond to the line numbers for the edi-
tor. Currently, two special kinds of lines may  be  used  to
format the listing: a line consisting of a form-feed charac-
ter, control-l, which causes a page eject  in  the  listing,
and  a  line with no characters which causes the line number
to be suppressed in the  listing,  creating  a  truly  blank
line.  These  lines  thus  correspond to `eject' and `space'
macros found in many assemblers. Non-printing characters are
printed as the character `?' in the listing.+

The standard procedure write

     If no minimum field length parameter is specified for a
write, the following default values are assumed:

           integer               10
           real                  22
           Boolean   length of `true' or `false'
           char                   1
           string       length of the string
           oct                   11
           hex                    8

The end of each line in a text  file  should  be  explicitly
indicated  by  `writeln(f)',  where `writeln(output)' may be
written simply as `writeln'. For UNIX, the built-in function
`page(f)'  puts  a  single  ASCII form-feed character on the
output file. For programs which are to  be  transported  the
filter  pcc  can  be  used to interpret carriage control, as
UNIX does not normally do so.

_________________________
+The character generated by a control-i indents to  the
next  `tab  stop'. Tab stops are set every 8 columns in
UNIX. Tabs thus provide a quick way of indenting in the
program.

Berkeley Pascal User's Manual                       PS1:4-57

A.3. Restrictions and limitations

Files

     Files cannot be members of files or members of  dynami-
cally allocated structures.

Arrays, sets and strings

     The calculations involving  array  subscripts  and  set
elements are done with 16 bit arithmetic. This restricts the
types over which arrays and sets may be defined.  The  lower
bound  of  such  a  range  must  be greater than or equal to
-32768, and the upper bound less than 32768. In  particular,
strings  may have any length from 1 to 65535 characters, and
sets may contain no more than 65535 elements.

Line and symbol length

     There is no intrinsic limit on the length  of  identif-
iers.  Identifiers  are  considered  to  be distinct if they
differ in any single  position  over  their  entire  length.
There is a limit, however, on the maximum input line length.
This limit is quite generous  however,  currently  exceeding
160 characters.

Procedure and function nesting and program size

     At most 20 levels of procedure and function nesting are
allowed.  There  is no fundamental, translator defined limit
on the size of the program  which  can  be  translated.  The
ultimate  limit is supplied by the hardware and thus, on the
PDP-11, by the 16 bit address space. If one runs up  against
the  `ran  out  of  memory'  diagnostic  the program may yet
translate if smaller procedures are used, as a lot of  space
is  freed  by  the translator at the completion of each pro-
cedure or function in the current implementation.

     On the VAX-11, there is an implementation defined limit
of 65536 bytes per variable. There is no limit on the number
of variables.

Overflow

     There is currently no checking for overflow  on  arith-
metic  operations at run-time on the PDP-11. Overflow check-
ing is performed on the VAX-11 by the hardware.

PS1:4-58                       Berkeley Pascal User's Manual

A.4. Added types, operators, procedures and functions

Additional predefined types

     The type alfa is predefined as:

        type alfa = packed array [ 1..10 ] of char

     The type intset is predefined as:

        type intset = set of 0..127

In most cases the context of an expression involving a  con-
stant set allows the translator to determine the type of the
set, even though the constant set itself  may  not  uniquely
determine  this  type. In the cases where it is not possible
to determine the type of the set  from  local  context,  the
expression  type defaults to a set over the entire base type
unless the base type is integer+. In  the  latter  case  the
type  defaults  to the current binding of intset, which must
be ``type set of (a subrange of) integer'' at that point.

     Note that if intset is redefined via:

        type intset = set of 0..58;

then the default integer set is the implicit intset of  Pas-
cal 6000-3.4

Additional predefined operators

     The relationals `<' and `>' of proper set inclusion are
available. With a and b sets, note that

        (not (a < b)) <> (a >= b)

As an example consider the sets a = [0,2] and b =  [1].  The
only relation true between these sets is `<>'.

Non-standard procedures

argv(i,a)                where i is an integer and  a  is  a
_________________________
+The current translator makes a  special  case  of  the
construct  `if  ...  in  [ ... ]' and enforces only the
more lax restriction on 16 bit arithmetic  given  above
in this case.

Berkeley Pascal User's Manual                       PS1:4-59

                         string variable assigns the (possi-
                         bly truncated or blank padded) i'th
                         argument of the invocation  of  the
                         current  UNIX  process to the vari-
                         able a. The range of valid i  is  0
                         to argc-1.

date(a)                  assigns the  current  date  to  the
                         alfa  variable  a in the format `dd
                         mmm yy ', where `mmm' is the  first
                         three characters of the month, i.e.
                         `Apr'.

flush(f)                 writes the output buffered for Pas-
                         cal file f into the associated UNIX
                         file.

halt                     terminates  the  execution  of  the
                         program  with  a control flow back-
                         trace.

linelimit(f,x)*          with f a textfile and x an  integer
                         expression causes the program to be
                         abnormally terminated if more  than
                         x lines are written on file f. If x
                         is less than 0  then  no  limit  is
                         imposed.

message(x,...)           causes the parameters,  which  have
                         the format of those to the built-in
                         procedure  write,  to  be   written
                         unbuffered  on  the diagnostic unit
                         2, almost always the user's  termi-
                         nal.

null                     a procedure of no  arguments  which
                         does absolutely nothing. It is use-
                         ful as a place holder, and is  gen-
                         erated  by  pxp  in  place  of  the
                         invisible empty statement.

remove(a)                where a is a string causes the UNIX
                         file whose name is a, with trailing
                         blanks eliminated, to be removed.

reset(f,a)               where a is a string causes the file
                         whose   name   is  a  (with  blanks
                         trimmed) to be associated with f in
                         addition  to the normal function of
                         reset.
_________________________
*Currently ignored by pdp-11 px.

PS1:4-60                       Berkeley Pascal User's Manual

rewrite(f,a)             is analogous to `reset' above.

stlimit(i)               where i  is  an  integer  sets  the
                         statement limit to be i statements.
                         Specifying the p option to pc  dis-
                         ables statement limit counting.

time(a)                  causes the current time in the form
                         ` hh:mm:ss '  to be assigned to the
                         alfa variable a.

Non-standard functions

argc                     returns the count of arguments when
                         the  Pascal  program  was  invoked.
                         Argc is always at least 1.

card(x)                  returns the cardinality of the  set
                         x, i.e. the number of elements con-
                         tained in the set.

clock                    returns an  integer  which  is  the
                         number  of  central  processor mil-
                         liseconds of user time used by this
                         process.

expo(x)                  yields the integer valued  exponent
                         of  the  floating-point representa-
                         tion    of     x;     expo(x)     =
                         entier(log2(abs(x))).

random(x)                where  x  is  a   real   parameter,
                         evaluated  but  otherwise  ignored,
                         invokes a linear congruential  ran-
                         dom  number  generator.  Successive
                         seeds are generated as (seed*a + c)
                         mod  m and the new random number is
                         a normalization of the seed to  the
                         range  0.0 to 1.0; a is 62605, c is
                         113218009, and m is 536870912.  The
                         initial seed is 7774755.

seed(i)                  where i is an integer sets the ran-
                         dom  number generator seed to i and
                         returns  the  previous  seed.  Thus
                         seed(seed(i))  has no effect except
                         to yield value i.

sysclock                 an integer function of no arguments
                         returns  the number of central pro-
                         cessor milliseconds of system  time
                         used by this process.

Berkeley Pascal User's Manual                       PS1:4-61

undefined(x)             a Boolean function. Its argument is
                         a real number and it always returns
                         false.

wallclock                an integer function of no arguments
                         returns  the  time in seconds since
                         00:00:00 GMT January 1, 1970.

A.5. Remarks on standard and portable Pascal

     It is occasionally desirable to prepare Pascal programs
which  will  be  acceptable  at  other Pascal installations.
While certain system dependencies are  bound  to  creep  in,
judicious  design and programming practice can usually elim-
inate most of the non-portable usages. Wirth's Pascal Report
concludes  with  a  standard  for implementation and program
exchange.

     In particular,  the  following  differences  may  cause
trouble  when  attempting to transport programs between this
implementation and Pascal 6000-3.4. Using the  s  translator
option may serve to indicate many problem areas.+

Features not available in Berkeley Pascal

     Segmented  files  and  associated  functions  and  pro-
     cedures.

     The function trunc with two arguments.

     Arrays whose indices exceed  the  capacity  of  16  bit
     arithmetic.

Features available in Berkeley  Pascal  but  not  in  Pascal
6000-3.4

     The procedures reset and rewrite with file names.

     The functions argc, seed, sysclock, and wallclock.

     The procedures argv, flush, and remove.

     Message with arguments other than character strings.

     Write with keyword hex.

     The assert statement.

_________________________
+The s option does not, however, check that identifiers
differ in the first 8 characters. Pi and pc also do not
check the semantics of packed.

PS1:4-62                       Berkeley Pascal User's Manual

     Reading and writing of enumerated types.

     Allowing functions to return structures.

     Separate compilation of programs.

     Comparison of records.

Other problem areas

     Sets and strings are more general in  Berkeley  Pascal;
see  the  restrictions given in the Jensen-Wirth User Manual
for details on the 6000-3.4 restrictions.

     The character set differences may cause problems, espe-
cially  the use of the function chr, characters as arguments
to ord, and comparisons of characters, since  the  character
set ordering differs between the two machines.

     The Pascal 6000-3.4 compiler uses a less strict  notion
of  type  equivalence.  In  Berkeley  Pascal, types are con-
sidered identical only if they are represented by  the  same
type  identifier.  Thus,  in  particular,  unnamed types are
unique to the variables/fields declared with them.

     Pascal 6000-3.4 doesn't recognize our option flags,  so
it  is wise to put the control of Berkeley Pascal options to
the end of option lists or, better yet, restrict the  option
list length to one.

     For Pascal 6000-3.4 the ordering of files in  the  pro-
gram  statement  has  significance. It is desirable to place
input and output as the  first  two  files  in  the  program
statement.

Acknowledgments

     The financial support of William Joy and  Susan  Graham
by  the  National  Science  Foundation  under  grants MCS74-
07644-A04, MCS78-07291, and MCS80-05144, and the William Joy
by an IBM Graduate Fellowship are gratefully acknowledged.

Generated on 2014-07-04 21:17:45 by $MirOS: src/scripts/roff2htm,v 1.79 2014/02/10 00:36:11 tg Exp $

These manual pages and other documentation are copyrighted by their respective writers; their source is available at our CVSweb, AnonCVS, and other mirrors. The rest is Copyright © 2002‒2014 The MirOS Project, Germany.
This product includes material provided by Thorsten Glaser.

This manual page’s HTML representation is supposed to be valid XHTML/1.1; if not, please send a bug report – diffs preferred.