Trailing-Edge
-
PDP-10 Archives
-
decuslib10-11
-
43,50531/pascal.doc
There are 7 other files named pascal.doc in the archive. Click here to see a list.
This document describes DECsystem-10 Pascal. This Pascal
system is the result of cooperation among a number of
different people. It was originally written at the
University of Hamburg by a group of people under the
supervision of Prof. H.-H. Nagel. This version was
developed from Prof. Nagel's by Charles Hedrick, and is
maintained by him. Lee Cooprider and others at the
University of Southern California have been particularly
helpful in supplying improvements, largely to the debugger.
A number of compiler bug fixes were supplied by Andrew
Hisgen at Carnegie-Mellon University.
Charles Hedrick originally intended to produce a system that
gave complete access to the facilities of the operating
system. To do this, a number of procedures were added, and
optional arguments were added to several existing
procedures. These additions give you access to the full
power of the DECsystem-10's input output system, as well as
to other facilities such as interrupt handling. While
making these additions, Dr. Hedrick ignored a number of
shortcomings in the design of the original compiler. More
recently, the goal has shifted to producing a complete
implementation of the language, with error handling and
debugging appropriate for student use. The standard in this
effort has been the PASCAL Revised Report. No attempt has
been made to implement the changes proposed for the ISO
standard. As a result of these two goals, this compiler is
now appropriate for both system programming and
instructional use. However it is still not an optimizing
compiler, and should not be used for applications where
high-quality code is important.
This system is now intended to be a complete implementation
of the language. The following are the only serious
limitations. A complete list will be found in an appendix.
1. Procedures can be passed as parameters to another
procedure. When calling a procedure that has been
passed in this way, you can supply no more than 5
parameters.
2. Sets of character are not fully implemented. Lower
case characters are treated as equivalent to the
corresponding upper case letter when in a set. All
control characters except tab are treated as
equivalent in a set.
This manual is intended as a complete reference manual for
this implementation. As such it contains far more detail on
extensions than many users will need. There is a somewhat
briefer manual, which is more suitable for the average user.
Both manuals describe only features that differ from those
documented in the Revised Report. So you should look at the
Revised Report first.
Page 2
1. Useage of the PASCAL Compiler
This compiler follows the standard DECsystem10 conventions
for compilers, and can thus be invoked by COMPIL-class
commands.
1.1 How to Use the PASCAL compiler
To compile and execute a PASCAL program TEST, you would
issue the command
EXECUTE TEST.PAS
The usual COMPIL switches, such as /NOBIN, /LIST, and /CREF
can be used.
If your program begins with a PROGRAM statement, execution
will begin by asking you for file spec's for each of the
files mentioned in the program statement. You should type a
standard DEC-10 file spec, terminated with <CRLF>. If you
do not type a file spec, but simply hit carriage return, you
will get the default for that file. INPUT and OUTPUT
default to "TTY:", usually your terminal. Other files
default to a disk file whose name is made from the
characters of the Pascal file name.
If you assign the file INPUT to a terminal, you will
normally be prompted for the first line of input by the
Pascal I/O system, [INPUT, end with Z: ]. Because of
oddities of the Pascal language, this initial read is done
before your program has started. Hence you cannot issue a
prompt first. This can be avoided by specifying INPUT to be
interactive (see below).
Note that the effect of listing a file in the PROGRAM
statement depends upon whether it is a predeclared file --
INPUT or OUTPUT -- or a file declared by the user. For a
user-declared file, listing it in the PROGRAM statement
simply provides an easy way to get a file specification for
it at runtime. It does not open the file. That is, you
must still do RESET or REWRITE on it. And you must still
declare the file identifier in the VAR section of the
program. However for the predeclared files INPUT and
OUTPUT, listing them in the PROGRAM statement also causes
the system to open them (RESET for INPUT, REWRITE for
OUTPUT).
If you choose not to use COMPIL-class commands, you should
say
.R PASCAL
*<relfile>,<listfile>=<sourcefile>/<sw>/<sw> ...
Anything other than the source file may be left out. The
defaults are:
Page 3
relfile: not produced if missing; if no extension:
.REL
listfile: not prodcued if missing; if no extension:
.LST
sourcefile: if no extension: .PAS
The possible switches are:
/ARITHCHECK - Turns on checking for arithmetic errors,
i.e. divide by zero, overflow, and underflow. If
this switch is not specified, the setting of
/CHECK is used as its default.
/CHECK - generates code to perform runtime checks for
indices and assignments to scalar and subrange
variables. Pointer accesses will also be checked
for NIL or zero pointers. (Usually a zero pointer
is the result of a pointer variable not being
initialized.) Divide by zero, overflow, and
underflow are also caught. All of these cases
cause an error message to be printed and transfer
to PASDDT or DDT if they are loaded. (If DDT is
loaded the program may be continued by "JRST
@.JBOPC$X".)
/CREF - generates information so that CREF can produce
a crossreference listing. Changes default
extension for the listing to .CRF.
/DEBUG - generate information for the DEBUG package.
This is normally on except for production
programs. We strongly encourage people to turn
this off (probably by putting the directive
(*$D-*) in their program) when they know they have
finished using PASDDT. The debug information may
double the size of your program.
/HEAP:nnn - This parameter has two different uses,
depending upon whether one is running on a KA-10
or not. In the usual (not KA-10) implementation,
this parameter specifies where the block of
storage used by NEW (the "heap") should begin.
NEW will begin allocating at the specified address
and go down. The only known use for this is if
you intend to load the high segment at other than
400000.
In the KA-10 implementation, dynamic core
expansion is not done. This parameter is used to
specify the total amount of core available for the
stack and heap. The default value is 2048 words.
If you get a message indicating that space has run
out for the stack or heap, you should expand this
parameter, or more likely, the comment {$H:nnn} at
the beginning of the source program. (See section
1.2)
/MAIN - a main program part is present (see Section
5.2)
/OBJECTLIST - list the generated code in symbolic form
/STACK:nnn - sets the first location to be used for the
stack. This should be above the high segment (if
Page 4
any). The only known use is if you intend to do a
GETSEG to a larger segment and want to be sure the
stack doesn't get in the way.
This parameter is probably meaningless in the
KA-10 implementation.
/VERSION:vvv - must be given on the output side. This
version number will be used for the .REL and .LST
files. It will also be put in .JBVER unless
overridden by a later directive. vvv is the usual
DEC-10 version number, e.g. 3B(22)-4. If no
/VERSION switch is given, the version number of
the input file (if any) will be used.
/ZERO - Causes code to be compiled in every procedure
and function prolog to initialize all of its local
variables to 0. Also, NEW will initialize all
records it generates to 0. This is useful mainly
for programs with complicated pointer
manipulations, since it guarantees that
uninitialized pointers will be 0, which will be
caught by the /CHECK code. Note that /ZERO and
/CHECK can be set independently, however, and that
/ZERO applies to all local variables, not just
pointers. /ZERO will not cause global variables
to be reinitialized, although they always start
out as zero unless an initprocedure is used to
give them another value.
To get the opposite effect of a listed switch, type
/NO<switch>. The default switch settings are /CHECK /DEBUG
/MAIN /NOOBJECTLIST /NOZERO. For /STACK and /HEAP the
arguments can be nnP, nnK, nnnnnn, or #nnnnnn. This
specifies a core address in pages, K, decimal, or octal.
The default values are 0, which causes 400000B to be used
for the heap and the stack to be put immediately above the
high segment. Values will be rounded up to the nearest page
boundary.
1.2 Core Allocation
On VM monitors (i.e. any Tops-10 system other than a
KA-10), PASCAL has dynamic core allocation. This means that
memory will automatically expand if you do NEW a lot, or use
a large stack. Thus if you get a message informing you that
you have run out of core, it means that you used all of your
virtual memory space. In such a case, you should reconsider
your data structures or algorithm.
Programs that do a lot of dynamic memory allocation should
consider returning spaced used by structures they are
finished with. Note that PASCAL makes no attempt to garbage
collect unused structures. This means that the programmer
must know when he is finished with a particular record
instance and DISPOSE it. DISPOSE is a standard procedure,
described in some editions of the Revised Report. It takes
Page 5
exactly the same arguments as NEW. However it returns the
space used by the record pointed to. This space can then be
reused by later NEW's. It is very important that any extra
arguments you supplied to NEW in generating the record be
supplied in the same way to DISPOSE. (These arguments are
used only for variant records, to allow allocation of space
for a particular variant.) If you do not use the same
parameters, you will get the error message: "DISPOSE called
with clobbered or already-disposed object". In addition to
checking validity of the disposed object in this way, the
runtimes also check for disposing NIL or 0, and give an
appropriate error message.
If your program uses memory in a strictly hierarchical
fashion, you may also find it possible to use the procedures
MARK and RELEASE to deallocate memory (See section 3.7).
RELEASEing an entire block of memory is more efficient than
DISPOSEing of records one by one, though this efficiency is
balanced by the fact that MARK and RELEASE are not part of
official Pascal (though they are present in most
implementations).
Note that you get a completely different version of NEW when
you use DISPOSE and when you do not. The system handles
loading the right version of NEW automatically. The version
used with DISPOSE is not compatible with MARK and RELEASE.
It is also not compatible with use of the /HEAP switch (or
$H directive) to start the heap at addresses above 377777
octal.
On a KA-10 the method of dynamic memory management used
under VM will not work. Thus the program at startup
allocates a fixed amount of space for the stack and heap.
The amount it allocates is under control of the /HEAP
switch, or a comment of the form {$H:nnn} at the beginning
of the program. If you don't specify anything, you will get
4 pages (2048 words) of storage, which should be enough for
small students programs, but not for big tasks. If your
program blows up because of an insufficient space
allocation, you would normally increase the space declared
in {$H:nnn} and recompile. If you want to avoid
recompiling, it is also possible to increase the amount of
space by using the monitor REENTER command. You may do a
REENTER before running a program, or after it has blown up
you may do a REENTER and then start it again (with the START
command). The REENTER processor will simply ask you to type
a number (in decimal). This will be the number of words of
storage to be allocated to the stack and heap. That number
will become the new allocation for this core image, and will
apply even if you restart the program. You can GET a saved
.EXE file, do REENTER, and SAVE it again if you want to
change the space allocation. You may also do REENTER with
the PASCAL compiler, in the unlikely event that the compiler
itself runs out of storage.
Page 6
1.3 How to Write a Program (Lexical Issues)
PASCAL programs can be written using the full ASCII
character set, including lower case. Of course some
characters (e.g. control characters) will be illegal except
in character or string constants. Lines are ended by
carriage-return/linefeed, form feed, or altmode (escape).
Lower case letters are mapped into the equivalent upper case
letters before being anaylzed by the compiler, although they
will appear in any listings exactly as read in.
Now we shall describe language elements which use special
characters.
Comments are enclosed in { and }, (* and *), /* and */, or %
and . For example
{This is an official comment}
(*This is a comment*)
%So is this\
(*And so \ is this *)
The switches mentioned above as appearing in the compiler
command line may also be set in the body of the program by
directives. Such directives take precedence over any
setting typed in the command string. These directives are
comments which start with a $ sign and have the form
(*$T+*) or %$T+\
A + after the letter indicates that the corresponding switch
should be turned on, a - that it should be turned off. More
than one switch setting can be given, separating them with a
comma:
(*T+,M-*)
The letters used in the directives correspond to the
switches in the following way:
A ARITHCHECK
C CHECK
D DEBUG
H HEAP
M MAIN
L OBJECTLIST
S STACK
V VERSION
Z ZERO
The form for H and S is (*$H:400000B*), etc. The form for V
is (*$V:2200000000B*), etc., i.e. the version number in
octal. This setting will not affect the version number
given to the output files, but will go in .JBVER. Thus it
will be the version number of the loaded program, and of any
Page 7
.EXE file.
Note that setting or clearing C also sets or clears A, so
order matters. To clear C, but leave A on, you should do
something like {$C-,A+}. This is consistent with the
overall approach wherein the default value of ARITHCHECK is
the same as CHECK.
Identifiers may be written using the underline character to
improve readability, e.g.:
NEW__NAME
Strings are character sequences enclosed in single quotes,
e.g.:
'This is a string'
If a quote is to appear in the string it must be repeated,
e.g.:
'Isn''t PASCAL fun?'
Note that mapping of lower case to upper case is not done
inside strings.
An integer is represented in octal form if it consists of
octal digits followed by B. An integer is represented in
hexadecimal form if it consists of a " followed by
hexadecimal digits. The following representations have the
same value:
63 77B "3F
Several PASCAL operators have an alternate representation.
The alternate form is provided for compatibility with older
versions of PASCAL. The form of the operator shown in the
left column should be used in new programs.
operator alternate form explanation
>= " greater or equal
<= @ less or equal
AND & logical and
OR ! logical or
NOT $ logical negation
<> # not equal
+ OR,! set union
* AND,& set intersection
2. Input/Output
Page 8
Input/Output is done with the standard procedures READ,
READLN, WRITE, and WRITELN as described in the Revised
Report on PASCAL [1,2].
2.1 Standard Files
In addition to the standard files INPUT and OUTPUT the
standard file TTY is available in DEC10 PASCAL. This file
is used to communicate with the terminal. The standard
files can be directly used to read or write without having
to use the standard procedures RESET or REWRITE. Note that
these files are logically declared in a block global to all
of your code. Specifically, if you use external procedures,
those procedures may also refer to INPUT, OUTPUT, and TTY,
and the same files will be used as in the main program.
As described in the Revised Report, the files INPUT and
OUTPUT are openned for you automatically if you mention them
in your PROGRAM statement. The file TTY does not need to be
openned, since it is "hardwired" to the terminal. (Indeed
mentioning TTY in the program statement is completely
useless. Doing RESET or REWRITE on TTY is also almost
completely useless, except that RESET can be used to
establish lower to upper case conversion or to let you see
end of line characters. However any file specification
given in RESET will be ignored.) )
2.2 File Declaration
Files that you declare follow the normal scope rules. That
is, they are local to the block in which they are declared.
This means that a file F declared in the main program is a
different file than a file F declared in a file of external
procedures, or in a different block. To use the same file
in an external procedure, you should pass it as a parameter
to the procedure. (It must be passed by reference, i.e.
declared with VAR in the procedure header.)
You have two opportunities to specify what external file
name you want associated with a Pascal file variable (e.g.
that you want INPUT to refer to "TTY:"). One is by listing
the file variable in the PROGRAM statement. This has been
described above. The other is by supplying a file name as a
string when you use RESET or REWRITE. If you do not supply
a file name in one of these ways, the file is considered
"internal". That is, Pascal will choose a filename for you,
and will do its best to see to it that you never see the
file. When you exit from the block in which the file
variable was declared, Pascal will delete the file. Such
files are useful for temporary working storage, but
obviously should not be used for the major input and output
of the program.
Page 9
2.3 RESET and REWRITE (simple form)
Except for the standard files, a file must be "opened" with
the standard procedure RESET when it is to be used for
reading. It must be "opened" with the standard procedure
REWRITE when it is to be used for writing.
RESET and REWRITE may have up to 6 parameters in DEC10
PASCAL. However, most users will need only 2 or 3 of them,
so the others are deferred until section 3.8.
RESET (<file identifier>,<file spec>,<protection>)
Only the first parameter is required. The other parameters
are used as follows:
<file spec>
This parameter must be of type PACKED ARRAY of CHAR.
Any length is acceptable, and string constants may
also be used. The parameter is expected to be the
usual DEC-10 file spec:
DEV:NAME.EXT[P,PN,SFD,SFD,...]. Device defaults to
DSK:. The other things default to blank. If you make
a syntax error, the operation fails, as if the file
were not found. In this case, the current file name
is not changed.
If you omit this parameter, the last file spec used
with this file will be used again. If no previous
file spec has been given the file spec entered in
response to the PROGRAM statement in the starting
dialogue will be used. If the file was not listed in
the PROGRAM statement, and you do not specify a file
name some time when you open the file, it will be
considered "internal", as described above. To omit
the file spec parameter when further parameters are
specified, use a null string, i.e. ''.
It is possible to specify :@ after the file spec, for
compatibility with Tops-20. Normally one would use a
null file spec in this case, e.g. '':@. This causes
the actual file spec to be read from the terminal.
The interaction between reading of the file spec and
normal TTY I/O is somewhat hard to specify, and in
general we do not recommend this form except with
programs intended to do a GTJFN from the terminal on
Tops-20.
<protection>
This parameter must be of type INTEGER. It represents
the protection to be given to an output file. This
parameter should not be used for input files unless
you have read section 3.8 and understand its special
effect. If it is omitted or zero, your default
protection is used. Note that the protection should
be right-justified in the word, unlike the former
055000000000B kludge. Thus a typical protection would
Page 10
be 055B.
In the following example REWRITE is used to give the file
OUTPUT the actual file name TEST.LST. The file is created
with protection <057>.
Example: REWRITE(OUTPUT,'TEST.LST',057B)
Note that RESET and REWRITE can fail, due to various errors
and strange hardware situations. In such a case, EOF is set
to show the further operations on the file will not work
(true for input, false for output).
2.4 Formatted Output
Parameters of the standard procedure WRITE (and WRITELN) may
be followed by a "format specification". A parameter with
format has one of the following forms:
X : E1
X : E1 : E2
X : E1 : O
X : E1 : H
E1 is called the field width. It must be an expression of
type INTEGER yielding a non-negative value. If no format is
given then the default value for E1 is for type
INTEGER 12
BOOLEAN 6
CHAR 1
REAL 16
STRING length of string
Blanks precede the value to be printed if the field width is
larger than necessary to print the value. Depending on the
type involved, the following is printed if the field width
is smaller than necessary to print the value:
INTEGER(normal) field width increased to fit
INTEGER(octal) least significant digits
INTEGER(hex) least significant digits
REAL field width increased to fit
BOOLEAN field width increased to fit
STRING leftmost characters
A maximum of 7 significant digits will be printed for real
numbers. Rounding is done at the seventh digit (or the
rightmost digit, if the format does not allow a full seven
digits to be displayed). Because of the automatic expansion
of formats for normal integers and reals, a field width of
zero is a convenient way to get a free format output.
The minimal field width for values of type REAL is 9. The
representation used for a field width of 9 is b-d.dE+dd,
where b is a blank, - a minus sign or blank, d a digit, and
Page 11
+ a plus or minus sign. As the field width is increased,
more digits are used after the period, until a maximum of 6
such digits is used. After than point, any increased field
width is used for leading blanks.
Example: WRITELN('STR':4, 'STR', 'STR':2, -12.0:10);
WRITELN(15:9, TRUE, FALSE:4, 'X':3);
The following character sequence will be printed (colons
represent blanks):
:STRSTRST -1.20E+01
:::::::15::truefalse::X
(Note that the field width for FALSE has been expanded in
order to fit in the output.)
A value of type REAL can be printed as a fixed point number
if the format with expression E2 is used. E2 must be of
type INTEGER and yield a non-negative value. It specifies
the number of digits following the decimal point. Exactly
E2 digits will always be printed after the point. The
minimal field width for this format is E2 + D + S + 2, where
D represents the number of digits in front of the decimal
place, and S is 1 if the number is negative and 0 otherwise.
The extra 2 places are for the decimal point and a leading
blank. There is always at least one leading blank, as
required by the Revised Report. Extra field width will be
used for leading blanks.
Example: WRITELN(1.23:5:2, 1.23:4:1, 1.23:6:0);
WRITELN(1.23:4:3, 123456123456:0:0);
The following character sequence will be printed (colons
represent blanks):
:1.23:1.2::::1.
:1.230:123456100000.
The :1.230 is a result of automatic format expansion, since
the specified 4 spaces was not enough. The 123456100000
shows that numbers will be rounded after 7 significant
digits.
A value of type INTEGER can be printed in octal
representation if the format with letter O is used. The
octal representation consists of 12 digits. If the field
width is smaller than 12, the rightmost digits are used to
fill the field width. If the field width is larger than 12,
the appropriate number of blanks preceded the digits.
Example: WRITE(12345B:2:O, 12345B:6:O, 12345B:15:O);
The following character sequence will be printed (colons
represent blanks):
Page 12
45012345:::000000012345
A value of type INTEGER can also be printed in hexadecimal
representation if the format with letter H is used. The
hexadecimal representation consists of 9 digits. Using the
format with letter H, the following character sequence will
be printed for the example above (colons indicate blanks):
E50014E5::::::0000014E5
2.5 The Standard Files
There are three files which may be initialized by PASCAL for
the user automatically. These are INPUT, OUTPUT, and TTY.
If you list them in the program statement, INPUT and OUTPUT
are initialized by implicit RESET(INPUT) and REWRITE(OUTPUT)
statements before the beginning of your program. The system
will ask you for file specs for these files before openning
them. If you want INPUT to be openned interactively
(interactive files are explained later in this section), you
should put :/ after INPUT in the program statement. E.g.
PROGRAM P(INPUT:/,OUTPUT). It is also permitted to use +
and - after the colon, for compatibility with Tops-20,
however at the moment these characters have no effect on
Tops-10.
TTY is always initialized on the user's terminal. For most
purposes one may assume that TTY is both RESET and
REWRITTEN, i.e. that it can be used for both read and write
operations. As in standard PASCAL, the default file for
those standard procedures that read is INPUT, and for those
that write, OUTPUT. If I/O is to be done on the terminal,
the file TTY must be mentioned explicitly as the first
argument to the I/O procedures.
In general TTY can be used with any of the read or write
procedures. Actually, however, this is somewhat of an
illusion. Internally, the file TTY is only usable for
input, and the file TTYOUTPUT is used for output. The user
need not normally be aware of this, as all mentions of TTY
in output procedures are automatically transformed into
TTYOUTPUT. However, for obvious reasons, such mapping
cannot be done with buffer variables. Thus should one wish
to work with the buffer directly, TTYOUTPUT^ should be used
for output. TTYOUTPUT must also be used explicitly with PUT
and REWRITE. Note however that TTY is directly connected
with the user's terminal via TTCALL's. REWRITE and RESET
cannot be used to alter this.
Because of the use of TTCALL I/O, output to TTY is not
buffered. This allows the user to type in on the same line
where the output appeared. Should a similar effect be
required on other files, BREAK(<file>) would be needed to
Page 13
force out the buffer.
In standard PASCAL, RESET(file) does an implicit GET(file),
so that file^ contains the first character of the file
immediately after the RESET is done. This is fine for disk
files, but for a terminal it makes things difficult. The
problem is that RESET(TTY) is done automatically at the
beginning of the program, so the program would go into TTY
input wait before you had a chance to prompt the user for
input. To solve such problems, many implementations allow
you to specify a file as interactive. Such a specification
keeps RESET from doing the implicit GET. In this
implementation, TTY is always interactive. Other files can
be made interactive by specifying a non-zero third argument
in the RESET. (The distinction is irrelevant for REWRITE,
and the third argument is used for file protection for
REWRITE.) When INPUT is openned implicitly by the PROGRAM
statement, it can be made interactive by using INPUT:/, as
mentioned above.
For an interactive file, file^ will not contain anything
useful until you do an explicit GET. To indicate this fact,
the system automatically sets EOLN(file) true after RESET.
Thus any program that checks for EOLN and does READLN if it
is true will work correctly. (This is done automatically by
READ with numerical and Boolean arguments.)
2.6 Character Processing
Any character except null (0) can be read or written by a
PASCAL program. In the normal case, end of line characters
appear in the buffer (e.g. INPUT) as blanks. This is
required by the specifications of the Pascal language. To
tell whether the file is currently positioned at an end of
line, EOLN should be used. When EOLN is true, the buffer
should contain some end of line character (although what
actually appears there is a blank). To get to the first
character on the next line do READLN. (If the next line is
empty, of course EOLN will be true again.) This is done by
the system routine READ when it is looking for numerical
input.
Note that carriage return, line feed, form feed, altmode,
and control-Z are considered to be end of line characters.
However, if the end of line was a carriage return, the
carriage return and everything up to the next end of line
(typically a line feed) is considered a single character.
If it is necessary to know which end of line character
actually appeared, the user can RESET the file in a special
mode. When this mode is used, the end of line character
appears in the buffer unchanged. You can still tell whether
the buffer is an end of line character by using EOLN (indeed
this is the recommended practice). In this mode, carriage
return is seen as a single character, separate from the line
Page 14
feed. However READLN will still treat a carriage return and
line feed as a single end of line. To be precise, READLN
will skip to the next line feed, form feed, altmode, or
control-Z before returning. To open a file in the mode
where you see the end of line character, specify /E in the
options string used in the RESET (see section 3.8.3) or in
the case of INPUT being implicitly openned by the PROGRAM
statement, specify INPUT: . You may request the special
file TTY to be openned in this mode by listing TTY: in your
program statement.
Control-Z is also considered the end of file character for
normal files openned on terminals (but not the special file
TTY, which has no end of file condition).
Terminal I/O is done in such a way that control does not
return to the program until G, L, Z, <alt>, <cr>, or <lf> is
typed. This allows the normal editing characters U, R,
<del>, etc., to be used. This is true with normal files
open on terminals as well as the file TTY.
It is possible to cause all lower case letters to be turned
into the equivalent upper case when they are read by your
program. To set up this process, specify /U in the options
string used in the reset. (See section 3.8.3)
Alternatively, once the file has been openned, you can do
UPCASE(<file>,TRUE). UPCASE must be declared EXTERN. (See
section 3.13.)
2.7 Reading characters
In official Pascal one cannot use READ or READLN to read
into arrays of CHAR. Thus one sees many programs full of
many loops reading characters into arrays of CHAR,
cluttering up essentially simple algorithms. I have
implemented READ into arrays and packed arrays of CHAR, with
capabilities similar to SAIL's very fine string input
routines. An example of the full syntax is
read(input,array1:howmany:['@ ',':'])
This will read characters into the array array1 until one of
three things happens:
1. One of the characters mentioned in the "break set"
(in this case blank or colon) is read. This
character (the "break character") is not put into
the array. You can find it by looking at INPUT,
since this always contains the next character that
will be read by READ. Howmany (which can be any
integer variable) is set to the number of
characters actually put into the array.
Page 15
2. End of line is reached in the input. Again,
howmany is set to the number of characters put into
the array. You can test for this outcome by
looking at EOLN(INPUT).
3. The array is filled. In this case, INPUT is the
character that would have overflowed the array.
Howmany is set to one more than the size of the
array, in order to allow you to detect this case
uniquely.
If filling of the array is terminated by a break character
or end of line, the rest of the array is cleared to blanks.
There is some problem caused by the fact that the
implementation used for sets of characters does not allow
all 128 ASCII character codes. To avoid this problem, lower
case characters in the input are treated as break characters
if the corresponding upper case character is in the break
set. And all control characters are treated as break
characters if any control character is specified as a member
of the break set. (Tab is an exception - it is treated as a
separate character.) Note that these limitations are
actually limitations in set implementation. They have
nothing specific to do with I/O. For example, if a lower
case character is mentioned as a member of a set, its upper
case equivalent is actually put in. Thus if you use ['a']
or ['A'] as a break set, you get exactly the same results:
Both upper and lower case A are treated as break characters.
The break set can be omitted, in which case input breaks
only on end of line or when the array fills up. The integer
variable can also be omitted, in which case the count is not
given to the user. Thus the actual syntax permitted is
read(<array-name>[:<integer-var>[:<set-expression>]])
The user is cautioned not to confuse this syntax with the
field width specification for output: READ(X:I) does not
specify a field width of I. Rather I is set after the input
is done to tell how many characters were actually read.
3. Extensions to PASCAL
3.1 Input/Output to strings
It is often convenient to be able to use the number-scanning
abilities of READ to process a string of characters in an
array of CHAR. Similarly, it may be useful to use the
formatting capabilities of WRITE to make up a string of
characters. To allow these operations, this implementation
provides a facility to treat a packed array of CHAR as if it
were a file, allowing READ from it and WRITE to it. This
facility is equivalent to the REREAD and REWRITE functions
present in many implementations of FORTRAN.
Page 16
To make use of this, you must use a file that has been
declared FILE OF CHAR. Rather than using RESET or REWRITE
to initialize I/O, you use STRSET or STRWRITE instead.
These associate a string with the file and set the internal
file pointer to the beginning of the string (in the simplest
case). A typical call would be STRSET(FILE1,MYARRAY).
After that call is issued FILE1 can be used with READ, etc.,
and will take successive characters out of the array
MYARRAY. Similarly, one might do STRWRITE(FILE2,YOURARRAY),
and then use WRITE(FILE2,...) to write things into
YOURARRAY. Note that as with a RESET, an implicit GET is
done as part of the STRSET. Thus immediately after the
STRSET, the first character of the string is in the file
buffer.
It is possible to start I/O at a location other than the
beginning of the array. To do so, use a third argument,
which is the index of the first element to be transferred.
E.g. STRSET(FILE1,MYARRAY,5) means that the GET will
retrieve element 5 from MYARRAY. (This is MYARRAY[5]. It
is not necessarily the fifth element, since the index might
be -20..6 or something.)
There is a procedure to see where you currently are in the
string. It is GETINDEX(file,variable). Variable is set to
the current index into the array. This is the index of the
thing that will be read by the next GET (or written by the
next PUT).
Note that no runtime error messages will ever result from
string I/O. Should you run over the end of the string,
PASCAL will simply set EOF (or clear it if you are doing
output). It will also set EOF if you read an illegal format
number. (GETINDEX will allow you to discriminate these two
cases, if you care.)
There is also a fourth optional argument to STRSET and
STRWRITE. This sets a limit on how much of the array will
be used. It thus gives you the effect of the substring
operator in PL/I. For example, STRWRITE(F1,AR1,3,6) will
make it possible to change characters 3 to 6 inclusive. If
absent, the fourth argument defaults to the last location in
the array.
Note that arrays of types other than CHAR can be used. They
must be packed arrays, however. (In order for an array to
be considered packed, the elements must take up a half word
or less. You can declare an array PACKED ARRAY[..]OF
INTEGER, but it is not really considered packed.)
Of course the file and the array must have the same
underlying type. (This is checked.)
Page 17
Beware that it is possible to set a file to an array, and
then exit the block in which the array is defined. The file
is then pointing out into nowhere. This is not currently
detected.
3.2 Monitor calls
For those daring souls who want to have access to all the
facilities of the machine, it is possible to insert CALLI's
into your program. CALLI(2,I,J,VAL,SUCCESS) will do a CALLI
2. The accumulator will have I put in its left half and J
in its right half. The value of the accumulator after the
CALLI will be put into VAL. SUCCESS will be true iff the
CALLI skips. Note that I and J can be any expression. No
type checking is done. Don't say we didn't give you enough
rope! The first argument must be an integer constant, as
the CALLI is compiled inline. Many CALLI's have pointers to
locations or blocks in their right half. The compiler will
realize it if J is an array or record, and will use a
pointer to it rather than trying to evaluate it. Certain
UUO's do not want the half word format the above call sets
up. So three other syntaxes as possible:
CALLI(2,,I,VAL,SUCCESS) interprets I as a full word and
loads it into the accumulator. CALLI(2,:3,VAL,SUCCESS) uses
3 in the accumulator field, ignoring what is in 3. (This is
designed for things like EXIT or WAIT. These UUO's
interpret the AC field as something other than an AC. Be
sure not to use this format if the UUO is going to interpret
it as an AC! You have been warned!) The AC field value must
be an integer constant. CALLI(2,I:J,VAL,SUCCESS) puts I and
J in AC and AC+1. I and J are not type checked. REASSIGN
and a few other UUO's need such arguments.
Should you wish to do your own I/O using CALLI's (or
external MACRO procedures) you should use the integer
function GETCHN. It returns the number of the first free
channel, or -1 if there are none free. It must be declared
external if you want to use it. RELCHN may be used to
return a channel to the pool of available channels. It must
also be declared external, and has a single integer
argument. Please be sure you only return channels that have
been GETCHN'ed!! (To free a channel assigned by PASCAL,
CLOSE the file. CLOSE is a standard procedure.) For the
really daring, you may get the channel of a file that has
been opened by PASCAL. To do this, use CURCHN(file). This
returns an integer, and must be declared external.
3.3 INITPROCEDURE
Variables of type scalar, subrange, pointer, array or record
declared in the main program may be initialized by an
INITPROCEDURE. The body of an INITPROCEDURE contains only
assignment statements. Indices as well as the assigned
values must be constants. Assignment to components of
packed structures is possible if the components occupy a
Page 18
full word.
The syntax of an INITPROCEDUE is as follows (the parts
enclosed in [ and ] may appear 0 or more times):
<initprocedure> ::= INITPROCEDURE ;
BEGIN <assignments> END;
<init part> ::= <initprocedure> [ <initprocedure> ]
The <init part> must follow the variable declaration part
and precede the procedure declaration part of the main
program.
Note that INITPROCEDURES do not compile into code. Instead
they put the values specified into appropriate places in the
.REL file, so that the variables are initialized by loading
the program. This means that you should not attempt to call
an INITPROCEDURE. It also means that if you restart a
program (e.g. by ^C-START), the INITPROCEDURES will not be
redone. We recommend very strongly that INITPROCEDURES only
be used for constant data.
3.4 Extended CASE Statement
The CASE statement may be extended with the case OTHERS
which then appears as the last case in the CASE statement.
This case will be executed if the expression of the CASE
statement does not evaluate to one of the case labels.
In the following example it is assumed that the variable X
is of type CHAR:
CASE X OF
'A' : WRITELN('VALUE IS A');
'B' : WRITELN('VALUE IS B');
OTHERS : WRITELN('VALUE IS NEITHER A NOR B')
END %CASE STATEMENT\
3.5 LOOP Statement
The LOOP statement is an additional control statement which
combines the advantages of the WHILE and the REPEAT
statement.
The LOOP statement has the following syntax:
<loop statement> ::= LOOP
<statement> [; <statement> ]
EXIT IF <expression> ;
<statement> [; <statement> ]
END
Page 19
The expression must result in a Boolean value. Note that
there must be exactly one EXIT IF in each LOOP.
3.6 CLOSE and DISMISS
There is a limit of 16 files active at the same time. (This
is a monitor limitation that PASCAL can do nothing about.)
Should you need to use more than 16 files in a program, it
may be convenient to be able to release the channel of a
file you are finished with. To do this, execute
CLOSE(file). This does a monitor CLOSE and a RELCHN on the
channel of the previous file. CLOSE has the additional
advantage that it makes the file accessible. Unless CLOSE
is done, the file is not in your directory until the program
finishes. In particular, if the system crashes, you lose
all files that have not been CLOSEd. Like READ, GET, etc.,
the file name may be omitted. If it is, it defaults to
INPUT. Also, there is an optional integer parameter. If
this is specified, it is used as the address field of the
CLOSE UUO. See the Monitor Calls manual for the effect.
(Most users will never need to use this additional
parameter.)
In some cases, you will be creating a file and decide you
don't want it. For example a compiler discovers there are
errors in the program and wants to abort creating the .REL
file. DISMISS(file) will abort creation of the file. One
could also do REWRITE(file). The difference is that this
creates a new zero-length file, which will supercede any
previous version. DISMISS does not change any old version.
DISMISS release the channel in the same way as CLOSE.
3.7 MARK and RELEASE
MARK and RELEASE can be used to organize the heap like a
stack. Both have one parameter which must be of type
INTEGER.
MARK(X) assigns to X the current top of the heap. The value
of X should not be altered until the corresponding
RELEASE(X).
RELEASE(X) sets the top of the heap to X. This releases all
the items which were created by NEW since the corresponding
MARK(X). Use of release is dangerous if any of the records
released contains a file. DISPOSE of a record containing a
file will correctly close the file. However RELEASE is a
bit more wholesale, and files will not get closed.
Note that MARK and RELEASE are probably not useful with
programs that use DISPOSE, since DISPOSE invokes a dynamic
memory manager that does not allocate the heap as a simple
stack.
Page 20
3.8 I/O facilities for wizards only
PASCAL has the ability to use the full I/O capabilities of
TOPS-10. This includes unbuffered I/O, file updating, etc.
(However at the moment unbuffered I/O is not supported for
direct use by the programmer.) Most of these wierd options
are specified in arguments to RESET and REWRITE. The full
form of these procedures includes the following arguments:
RESET (<file identifier>,<file spec>,<protection>,
<xblock>,<buffers-and-bits>,<mode>)
Only the first parameter is required. Omitted parameters
are given the default value of 0 (except for <mode>, whose
default depends upon the type of file, and <file spec>,
whose default value is ''). In some cases the monitor will
replace this 0 with a default value. In other cases, the
PASCAL runtimes will supply its own default in place of a
zero.
For mode and buffers, which often involve specifying bits,
it is sometimes most convenient to specify the argument with
a set. Because of the representation of Pascal sets, [2,5]
gives you a word with bits 2 and 5 set (i.e. 1B2!1B5).
The form shown above is the old, full form of the RESET.
Because no one (including me) could remember which bit is
which, a new form is provided which allows you to set the
most useful bits by the use of switches. To do this, pass a
string for the third parameter, e.g.
RESET(F,'A.B','/I/E')
Here are the meaning of the switches. For details on what
they do, you will have to look below where the bits that
they set are described. Note that you can mix the two
notations, i.e. use a string for the third parameter and
then go on to set bits in the later parameters. The bits
set in the two ways are or'ed together.
/B:nn Byte size specification. The number
specified goes into the byte size field of the
OPENF word. It is mainly useful for handling
industry-compatible magtape, wherein 8 bit bytes
are useful. For details about the meaning of the
byte size, see section 3.8.3.4
/D Data transmission errors will be handled by the
user. See the section below on error handling
(section 3.8.6). A data transmission error is
usually a physical problem of some sort. See /F
for problems with the format of the data.
/E End of line characters will be visible to the
program. Normally Pascal programs put a blank in
the input buffer at the end of line. If this flag
Page 21
is set, the actual end of line character appears
in the buffer. Normally a single GET will read
past both a carriage return and a line feed, since
they are a single line terminator. But if /E is
set, the carriage return and the line feed will be
treated as separate characters, although READLN
will still skip them both.
/F Format errors in the data will be handled by the
user. See the section below on error handling
(section 3.8.6). A format error occurs when the
data is readable, but is not what READ wants.
E.g. when trying to read a number, a letter is
found.
/I Interactive file. The meaning of this has been
discussed above. It keeps the system from reading
the first component in the file, as it normally
does whenever a file is openned.
/O Open errors will be handled by the user. See the
section below on error handling (section 3.8.6).
An open error is an error that occurs during the
RESET, REWRITE, etc. Most commonly it is when the
specified file is not present or a protection
problem (e.g. you aren't allowed to read the
file).
/U Upper case the file. All lower case letters will be
turned into the equivalent upper case. Only
letters are affected.
The meaning of <file spec> has been discussed above. We
emphasize here that if the file spec is omitted or specified
as '' the previous file spec used with this <file
identifier> is used again (or if none has been given, the
file is treated as "internal", and is deleted when you exit
from the scope in which the file variable is declared).
3.8.1 Openning a file in interactive mode
Protection has also been discussed above. As was mentioned
in section 2.5, if <protection> is given a non-zero value
for an input file, the file is treated as an interactive
file. That is, the RESET does not GET the first character
in the file, as it usually would. Instead, the buffer
variable associated with the file is set to null or 0, and
EOLN(file) is set true. To emphasize this special
interpretation of the protection field for input files, I
usually use TRUE for interactive files and FALSE otherwise.
(FALSE is equivalent to 0.) Note that it may often be useful
to open magnetic tape files as interactive. Often the
program will open a tape with RESET and immediately do
rewind, skip a file, etc. In this case, it is cleanest not
to have RESET read the first record, as would happen if it
is not openned as interactive. Recall that TTY is always
openned in interactive mode. Even if an explicit RESET is
done by the user without specifying the interactive
argument, the implicit GET will not be done for TTY.
Page 22
3.8.2 Using an extended LOOKUP/ENTER block
The TOPS-10 monitor stores all sorts of wierd information
about files in what is called the RIB (Retrieval Information
Block). The user may find out about this information when
he opens a file for reading, or specify it when he opens it
for writing. To do so, he specifies an "extended
LOOKUP/ENTER block". It should be filled with information
to be used by the monitor in the case of a REWRITE. After a
RESET or REWRITE is done, the block may be examined to find
what information is returned by the monitor. For a list of
the actual information involved, consult the Monitor Calls
Manual, or your friendly systems programmer.
The <xblock> parameter may be an array or record of any
type. However, its length must be at least 5 words. It
will be used as an extended lookup/enter block for the
lookup or enter implied by the RESET or REWRITE. The file
spec and protection will be copied into it before use, but
everything else will be unchanged. Thus you should be sure
that things which should be zero are in fact zero. You will
be able to see the stuff the monitor put in it after the
return. WARNING: Be sure that you preset the number of
arguments in the first word of the block.
There are some circumstances (especially when you wish to
reuse a lookup block left over from a previous RESET) when
you do not want the protection specified in the third
argument to be put in the block. Thus if the third argument
is zero, the protection in the block will be used without
change. If the third argument to a REWRITE is non-zero, it
will always be used as the protection. Of course the third
argument to RESET will have the usual interpretation of
setting interactive mode whatever the value of the
protection field in the block.
The proper way to simulate a PIP copy command is to do a
reset using an extended lookup block, and then use the same
block for the rewrite without changing it, specifying a zero
protection argument. This will cause the output file to
have exactly the same characteristics, including creation
date, as the input file.
3.8.3 Controlling buffers and blocksize, etc.
The fifth parameter is a mess. It has sort of collected all
the random junk that won't fit anywhere else. One way to
set the various subfields in this parameter is to declare a
record with all the various fields and then pass it.
Alternatively, one can move values to the appropriate field
by multiplication. E.g. since the low-order bit of the
blocksize is bit 1000000B one could specify a blocksize of
BLSIZE and BLNUM buffers by BLNUM + BLSIZE * 1000000B. The
table below gives an appropriate record declaration,
together with the magic constants to multiply by the get the
Page 23
corresponding field, if you prefer to do it that way. No
doubt a future release of PASCAL will use a better method of
specifying these fields, probably using keywords.
PACKED RECORD
RECORD__BLOCKING: Boolean; 400000000000B (11 0's)
BLOCKSIZE: 0..377777B; 1000000B (6 0's)
INDUSTRY__MODE: Boolean; 400000B (5 0's)
MAP__LOWERCASE: Boolean; 200000B (5 0's)
FORCE__BUFFERED: Boolean; 100000B (5 0's)
SEE__END__OF__LINES: Boolean; 40000B (4 0's)
BYTE__SIZE: 0..77B; 1000B (3 0's)
NUMBER__BUFFERS: 0..777B no multiplier necessary
END
3.8.3.1 Number of buffers
The most common use of the fifth argument is to control the
number of buffers in a buffer ring, when you are using a
buffered mode (the usual case). Since this parameter is
right-justified in the word, you may simply specify it as an
integer or integer expression.
If it is zero, you will get whatever number of buffers was
in use for that file before. (If it is necessary to create
new ones, the default number for that device type will be
used.) The buffers will be of the standard size for the
device.
Note that when a file is openned for UPDATE, only one buffer
is actually used, although the number you request will be
allocated.
3.8.3.2 Block size
The next most common use of this parameter is to set the
block size. If the left half is non-zero, the runtimes will
attempt to set the physical block size of the device to the
value specified. Currently this is only implemented for
magnetic tapes. (A TAPOP. is used.) Note that when this is
done, the buffer size is automatically set to the same size
as the physical block size. An attempt to set a physical
block size for any device other than magtape will be
ignored.
Note that the block size specification is in bytes.
However, the actual block-size will be set to the equivalent
number of 36-bit words. If your block size does not produce
an even number of 36-bit words, it will be rounded up to the
nearest word.
3.8.3.3 Blocked records
Page 24
Normally bytes are put into the monitor's buffer until the
buffer fills, at which point it is put out and a new one is
begun. Thus there is typically no correlation between
Pascal records and the physical records on disk or tape.
Sometime it is desirable to make such a correlation.
Setting this bit causes each Pascal record GET or PUT to
start on a record boundary. It is thus useful for reading
variable-length records from tape.
More precisely, GET always reads exactly one record from the
I/O device. If the record is too big for the Pascal record
type, the extra bytes are ignored. If it is smaller than
the Pascal record, only the bytes actually read are copied
into the record buffer. (The rest of the buffer is
unchanged.)
PUT will always write one record or more. Normally it
writes one record. However if the Pascal record is bigger
than the buffer size for the device, it will be split into
more than one record.
The size of the record read or written can be found by
looking at LSTREC. This is the number of bytes copied to
the Pascal record buffer, so if the physical record was too
long, the extra bytes will not show in this number.
3.8.3.4 Byte size
Sometimes it is desirable to set the bytesize to be used for
a file. Normally the monitor sets it to 7 bits for ASCII
modes, 8 bits for PIM and byte mode, and 36 bits otherwise.
An example of a case where one might want another setting is
reading tapes from other machines. IBM 9-track tapes are
written in 8-bit bytes, so it would be reasonable to want to
set the byte size to 8 bits. Anyone who wishes to use this
parameter should read the note on byte sizes in section
3.8.8.
3.8.3.5 Industry-compatible magtape
It is possible to set industry-compatible mode for a
magtape. To do so, turn on the high-order bit in the right
half word. E.g. to read a tape from UNIX, IBM, etc., one
would probably specify 8*1000B+400000B. The 8*1000B is byte
size of 8, and the 400000B is industry-compatible mode. If
the tape uses the ASCII character set, the normal read and
write routines will then be able to handle it properly. I
can see no use for industry-compatible mode except with a
byte size of 8 (nor indeed can I see much use for a byte
size of 8 except with industry-compatible mode).
3.8.3.6 Mapping lower case to upper
Page 25
If you specify 200000B, all lower case letters input from
the file will be turned into upper case when you read them.
This only has an effect on text files (FILE OF CHAR) and
only works for input. It is precisely equivalent to calling
the procedure UPCASE for the file.
3.8.3.7 Force buffered mode for terminals
This is useful only for terminals. Terminal I/O is normally
done with the TRMOP. uuo (except for the special files TTY
and TTYOUTPUT, which are done with TTCALL). The advantage
of using TRMOP. is that output appears on the screen
immediately, rather than waiting until a buffer is filled.
However the overhead is greater, since a monitor call must
be done for every character. If bit 100000B is set, the
terminal will be openned and normal buffered I/O will be
done to it. To force output to appear on the screen, do a
BREAK on the file.
3.8.3.8 See end of lines
Normally, end up lines show up in your Pascal input buffer
as blanks. That is, carriage returns will be read by your
program as if they were blanks, except that EOLN will be
set. This EOLN tells you that what looks like a blank is
really some end of line character. Furthermore, a carriage
return/line feed will show as only one character (one
blank). In case you need to be able to tell which kind of
end of line character you have, you can set this bit. If
this bit is set, end of line characters will appear in your
buffer as themselves. Also, the carriage return and line
feed will each appear as separate characters.
3.8.4 I/O mode
The fifth parameter sets the initial status of the channel.
The meaning of the various bits is defined in the Monitor
Calls Manual, which should be consulted by anyone who uses
this parameter. The most-often used bits are the right-most
ones, which specify the I/O mode. The most useful values
for the mode are 0 for normal ASCII, 14B for binary, and 17B
for unbuffered I/O. The user need not normally worry about
the mode since by default 0 will be supplied for text files,
and 14B for all other. Please note that mode 17B is always
used internally for files openned for UPDATE. However the
mode specified by the user will be simulated in a manner
that is believed to be transparent.
The main case you would have to specify a mode is if you
need to use unbuffered I/O. However at the moment
unbuffered modes are not supported. Please ignore
references to them in the rest of this section. They are
left in because the implementation will probably be put back
in the near future.
Page 26
Note that the standard PASCAL I/O facilities can be used in
any mode for which they make sense. If GET or PUT is used
for a file openned in a unbuffered mode (15B to 17B), each
GET or PUT causes a single unbuffered transfer to or from
the PASCAL buffer variable. A file declared as TEXT (or
FILE OF CHAR) must not be openned for unbuffered I/O, since
the character routines cannot handle such modes. (Indeed
unbuffered I/O doesn't make sense for characters.) PUTX (See
the section on updating) may also be used with unbuffered
I/O. In such modes, each PUTX will rewrite the record
gotten by the last GET, using unbuffered I/O. If the last
record was not a multiple of 128 words, some old data may be
lost, since an unbuffered write always writes a multiple of
128 words. (In buffered modes, only the record changed is
rewritten, but this is not possible with unbuffered I/O.)
Also note that unbuffered I/O ignores logical blocking if it
is specified.
The routines DUMPIN and DUMPOUT, described below, are only
useable when the file is open in an unbuffered I/O mode.
3.8.5 Non-mode bits in the status word
Non-mode bits may also be set in the status word. The most
useful of these bits are in the left half of the word. For
instance, bit 0 (the left-most bit) represents physical-only
OPEN. To set such a bit, simply specify it as part of the
<mode> parameter.
3.8.6 User error recovery
Certain of the bits in the status word indicate that an
error of one type or another has happened for that file.
(These are the bits 740000B.) We assume the user has no
desire to set these bits himself. Thus if one of these bits
is specified in the <mode> parameter, the system will
consider that you are requesting that errors of the
corresponding type be ignored for this file. If one occurs,
SETSTS will be used to clear it, and I/O will continue as if
it had not. This will allow your program to attempt to
recover from the error, or even to ignore it if you wish.
If these magic bits are not set, any I/O error causes PASCAL
to print an error message on the user's terminal and
terminates the program. If the appropriate bit is set, this
does not happen. If the user simply wishes to ignore any
errors, he need do nothing special other than set the
appropriate bits in the <mode> parameter. However, if he
wishes to do error recovery, or even print a warning
message, a function ERSTAT is available to indicate whether
any errors have occurred, and if so which they are. If
ERSTAT is not used, errors will simply be ignored.
ERSTAT(file) is an integer which will have bits set
corresponding to any errors that have happened since the
last call to ERSTAT. If an error occurs that you are not
Page 27
enabled for, a fatal error message will be printed.
Note that as far as the monitor is concerned, an end of file
is an error. It sets bit 20000B in the file status word.
Since this is not really an error, programs are always set
to handle end of file conditions themselves. Thus an end of
file will not result in an error message unless the program
fails to test EOF and continues to try to read. An end of
file will set bit 20000B in ERSTAT, and make EOF true. An
EOF condition does not abort the program, so you should
check for EOF yourself if you want the program to stop on
that condition.
There is two kinds of error that is are not detected by the
monitor as I/O errors, and hence do not have a bit in the
set 740000B to represent it. The first such case is
incorrect data in the file. For example, suppose
READ(INFILE,I) is done, where I is an integer, and something
other than an integer is found. Normally this results in a
fatal error message. However, if bit 10000B is set in
<mode>, this action is inhibited. When a data format error
occurs and this bit is set, EOF will be set for the file,
and 010000B will be put in the ERSTAT word. (Note that I/O
from strings, described elsewhere, always operates in this
mode.)
The second kind of error that does not have an error bit
defined by the monitor is an error during file openning
(file not found, etc.). Normally such errors result in
fatal error messages. To prevent this from happening, set
but 4000B in <mode>. When you set this bit, EOF will be set
after the RESET, REWRITE, etc., if it fails. ERSTAT will
show bit 4000B, and in addition the monitor's lookup/enter
code will be right-justified in the ERSTAT word. ANALYS
will print an official-looking error message if you call it.
3.8.7 Non-blocking I/O
Should you be using non-blocking I/O, an I/O operation that
fails will set EOF, but ERSTAT will be 0. (On output, it
will clear EOF, of course.) This should be the only case
where EOF is set and ERSTAT is 0. To retry the operation,
you must use CLREOF (see section 3.13) to clear EOF. Then
you must get PASCAL to reissue the failing UUO.
Non-blocking I/O can be used successfully only for files
made up of objects taking up one word or less. Furthermore,
trouble will occur for a TEXT file having line numbers if a
line number appears at the end of a disk block and the
following tab at the beginning of the next. (This is a
violation of the standards for line numbering, however, and
SOS will never produce such a file.) If these limitations
are followed, you use CLREOF and then reissue the GET or PUT
that failed.
Page 28
3.8.8 A note on byte sizes in files
The documentation above describes I/O as occurring in bytes.
On the DECsystem-10 a word contains 36 bits. It may be
divided into smaller units called bytes. The bytes will be
left justified, and will not be split across words. Thus
7-bit ASCII text is stored in 7-bit bytes, 5 to a word, left
justified. I/O gets bytes from the monitor buffer (Don't
confuse this with the PASCAL file buffer!) one at a time,
unpacking them if there is more than one byte per word.
There are two types of PASCAL I/O: text and record. Text
I/O is what you get when you use TEXT or FILE OF CHAR. The
PASCAL runtimes assume that every GET from a text file
returns one ASCII character (and that every PUT puts out one
character). Internally GET just gets one byte from the
monitor buffer. Thus everything works nicely for the usual
kind of file, assuming you accept the default byte size of 7
bits. Since the usual file has characters packed 5 to a
word, getting one byte out of the file does indeed get one
character. However, you can change the byte size. If you
used a byte size of 8 bits with a normal file, there would
obviously be trouble, since the 5 characters stored in each
word would be distributed over 4 bytes of 8 bits each. The
usefulness of a byte size of 8 is for industry-compatible
magnetic tapes. Since these tapes in general contains 8-bit
ASCII or EBCDIC, the monitor packs 8-bit bytes 4 to a word
in the monitor buffer. In the case of ASCII the high-order
bit of the byte is parity, and may be ignored. So to read
such a tape one must (explicitly or implicitly) specify a
byte size of 8 bits, so that when GET gets a byte the byte
is really one character. A byte size of 36 bits would make
sense for text files only in certain wierd I/O modes where
the monitor packs data one character per word. That is
because a byte size of 36 bits means that each GET returns
one word, with no unpacking. Because text I/O is assumed to
involve ASCII characters, each byte is truncated to the 7
low order bits immediately after input. Thus in case parity
in included as an 8th bit, it will not mess up the runtimes.
Should you need to see the parity, you will have to make
other arrangements, probably by using record I/O with a
record type PACKED ARRAY OF 0..377B.
Record I/O is any I/O not involving a FILE OF CHAR. In this
case data is transferred from the monitor buffer to the
PASCAL file buffer (FILE^) by putting each byte gotten from
the monitor into a separate word in the PASCAL record. Thus
a byte size of 36 bits causes the PASCAL record to have the
same structure as the file. If a byte size of 7 bits were
used, each 7-bit byte in the file would be moved to a
separate word in the PASCAL record. Thus it would be
appropriate if the file is a usual text file, but the PASCAL
record is an unpacked array of CHAR. Note that the I/O
runtimes do not check the byte size to be sure it makes
sense. So it would be perfectly possible for you to use a
Page 29
byte size of 7 bits to read into a PACKED ARRAY OF CHAR,
even though that would make no sense. It makes no sense
because it causes one 7-bit byte from the file to be put in
each word of the PACKED ARRAY. But a PACKED ARRAY OF CHAR
should have 5 characters in each word. Except for special
effects, one usually uses a byte size of 36 for record I/O.
Then each input word is moved into a word in the record, and
you can do what you like with it.
You can now understand why the default I/O modes use 7 bit
bytes for text I/O and 36 bit bytes for record I/O.
3.8.9 Errors in file openning
Note that RESET and REWRITE can fail, due to various errors
and strange hardware situations. In such a case, the system
will normally print an error message of the same type that
standard system programs use (e.g.
? F.F (0)File not found). If you want to handle these
errors yourself, specify 4000B in the <mode> parameter to
the RESET or REWRITE. Or more conveniently, specify '/O' in
the options. If you do that, a failing open will return
normally, with EOF set to show that problems occurred. You
can use ERSTAT to get the error number (it will be in the
right-most 7 bits, along with the 4000B bit). Or you can
call the procedure ANALYS, which will print the same error
message that would have been printed automatically by the
system. ANALYS should be declared external, and takes one
parameter, a file (passed by reference). If no error has
occurred, ANALYS will do nothing.
The right-most 7 bits returned by ERSTAT will be the error
code as given in the monitor calls manual for LOOKUP/ENTER,
except for the following additional ones:
102 illegal syntax in file spec
103 all I/O channels are in use
Note that these codes are decimal.
3.8.10 Variable Record Formats
Standard PASCAL has a problem when it tries to read files
created by non-PASCAL programs. Every call to GET or PUT
transfers a fixed number of words and puts it into the
buffer variable. This is fine for files whose records are
all the same length and format, but for other files it is a
mess.
To avoid these problems, we have extended the format of the
GET and PUT, to allow GET(<file>[,<variant>]*[:<array
size>]), or the equivalent for PUT. If the file type is a
variant record, you may use FILE,VAR1,VAR2... to specify
the exact variants. This is exactly like the syntax for
NEW, as documented in the Revised Report. Furthermore, if
Page 30
the file is an array, or the selected variant ends in an
array, you may specify the number of elements in the array
to be used. For example we might have
TYPE REC=RECORD CASE BOOLEAN OF
TRUE: (INT:INTEGER);
FALSE: (J:BOOLEAN,K:ARRAY[1:100]OF INTEGER)
END;
VAR F:FILE OF REC;
BEGIN
RESET(F,TRUE); %TRUE to prevent the implicit GET\
GET(F,TRUE); %TRUE to select the variant "TRUE"\
GET(F,FALSE,5);
GET(F)
END.
The first GET would read one word of the file, since the
variant TRUE requires only one word. The second GET would
read 6 words of the file. One word is for the Boolean J,
and 5 for the first five elements of K, since the argument 5
specifies that only 5 are to be used. The final GET would
read 101 words from the file, which is the space required
for the longest possible variant. Note that the argument
after the colon is an index into the array. (I.e. if the
array is [-5:1], 1 means all 7 members of the array.)
In some cases it is necessary to read a record in more than
one piece. For example, the record might begin with a type
code. Obviously we have to read the code before we can
specify how to read the rest of the record. Thus there is a
procedure, GETX, to continue reading a single record. With
GETX, the data transfer begins when the previous GET
stopped, rather than at the beginning of the record.
Suppose our record is a simple array of integers. Then we
might do GET(file:1) to read a length code, and GETX(file:L)
to read the rest of the record. Note that after the GETX
the code is still present in the buffer as the first member,
so the L counts it.
Also, sometimes you will need to know how much space a given
variant will take up. Of course you can calculate this if
you know the way PASCAL allocates memory. But it is more
elegant to let PASCAL do the calculation for you.
RECSIZE(file) will return the number of bytes in a record
for the file. All the variant and length options of GET and
PUT can be used, so that the size of any version of the
record can be calculated. E.g. RECSIZE(file,TRUE) returns
the size of the TRUE variant.
3.9 RENAME and DELETE
There is an extra runtime, RENAME. Its arguments are the
same as for RESET and REWRITE, i.e
RENAME(file,name,protection,xblock). It renames the file as
specified. You had better have done a RESET or REWRITE on
Page 31
file!! EOF is set false if it works, true if not. You can
use ANALYS to print error messages if it doesn't work. Note
that the monitor RENAME function that underlies this
procedure does a monitor CLOSE. This means that after a
RENAME, if you wish to keep accessing the file, you must do
RESET on it again. If you forget to do so, you will get an
I-O error on that file. Although it does a monitor CLOSE,
RENAME does not imply a PASCAL CLOSE (i.e. releasing the
channel for other uses). So it would make sense to call
CLOSE after doing RENAME, even though it is not necessary.
DELETE(file) can be used to delete the file currently open.
It is equivalent to RENAME(file,' '). We recommend using
DELETE rather than RENAME to delete files, since it is
clearer, and is compatible with the Tops-20 implementation.
The various comments about RENAME are applicable to this
function too.
3.10 UPDATE [also DUMPIN and DUMPOUT]
You may open a file for updating by using the runtime
UPDATE. Update has the same arguments as RESET. It differs
from RESET in that it opens the file in a special manner
such that the contents may be changed as well as read. You
may intermix read and write operations on such a file with
no problems, except that you can always write but you can
only read the current position is before the end of file.
Writing beyond the end of file extends the end of file.
Note that the third argument to UPDATE is interpreted as
with REWRITE rather than RESET. I.e. it is the file
protection, not a flag to suppress the initial implicit GET.
(This GET never happens for UPDATE.)
Note that it is not necessary to do a RESET before doing an
UPDATE. However, if you need to use information from the
extended lookup block for your ENTER, you will need to do a
RESET to set this information. Any extended lookup block
supplied to UPDATE is used only for the ENTER operation.
If you don't specify an extended enter block, the file's
access date will be changed to today, and its protection
will be left unchanged (even if you specify a non-zero
protection argument - this is a monitor feature, not
PASCAL). If you do specify an extended block, the access
date, etc., in it will be used, and the protection argument
will be inserted into it. However as a special convenience
if the protection argument is zero, the protection code in
the block is left unchanged. Thus in order to leave the
date, etc., of a file unchanged, you merely use the extended
lookup block left over from a RESET, not changing anything
in it.
When you have opened a file with UPDATE, you can then use
the procedure PUTX, in conjunction with GET. To update a
record, you would do GET to read it, change the contents of
Page 32
the PASCAL buffer variable corresponding to the file
involved (i.e. FILE^), and then do PUTX(FILE). Note that
PUTX takes only one argument, the file. It always rewrites
exactly the same record as was read by the last GET (or the
whole record read by a combination of GET and GETX -- See
the section on variable records). This is just a
convenience for record operations. You could accomplish the
same result by repositioning the file to the beginning of
the record and rewriting it with PUT.
When a file is openned with UPDATE, the I/O is actually done
in mode 17B (dump mode), for the sake of efficiency.
However this fact should be invisible to the user. The byte
size and other aspects of the mode you request will be
simulated.
Updating may also be done with the procedures DUMPIN and
DUMPOUT, assuming that the file was openned in an unbuffered
I/O mode (15B - 17B). DUMPIN(file,variable,size) reads size
words from the file into variable. No type checking is
done, but if /CHECK is in effect the system verifies that
size words will fit in variable. This transfer is done with
a single unbuffered read. DUMPIN(file,variable) is a legal
abbreviation. The number of words it transfers is taken
from the size of variable. I.e. variable is "filled up".
DUMPOUT(file,variable,size), or DUMPOUT(file,variable)
writes the contents of variable. Note, however, that
unbuffered I/O is current not implemented, so at the moment
these procedures do not exist.
3.11 Random access
It is possible to move around a file randomly when it is on
a direct-access device (i.e. disk or some equivalent). The
procedures that implement this use a byte serial number to
keep track of their position. I will henceforth call this
the "position". This number refers to the number of bytes
between the beginning of the file and the record in
question, so the first record begins at position 0. The
position is absolute within the file, so if blocking causes
certain parts of the file to be skipped, gaps are left in
the position numbers. Note that the unit of measure is the
byte. This corresponds to one word in the PASCAL buffer.
However in the file itself the bytes may be packed,
depending upon the I/O mode in which it was openned. TEXT
files (FILE OF CHAR) are stored 5 bytes per word by default.
Other files are one byte per word by default.
CURPOS(FILE) returns the current position index of the file.
This is the position at which the next record to be read or
written would begin. When a file has just been openned, the
position is, of course, 0. If EOF is on (or off, for output
files), CURPOS returns -1. Note that CURPOS has
unpredicable results if it is used with a file that is not
on disk, and gives an error if used with a file open on a
Page 33
string. (But GETINDEX gets a similar effect for the last
case.) If you clear EOF via CLREOF CURPOS will no longer
return -1, but you still should not believe its results. If
EOF was set because of failure of non-blocking I/O and you
reissue the failing operation, CURPOS will be correct after
that operation succeeds, but not until then. CURPOS is a
builtin function.
SETPOS(F,B) sets things up so the next GET(F) or PUT(F) will
get or put the record that starts at position B. SETPOS
does an implied GET. To surpress this implied get, use an
extra non-zero argument, e.g. SETPOS(F,6,TRUE). SETPOS is
also a builtin procedure. SETPOS is only possible on files
for which input is allowed. I.e. it works when RESET or
UPDATE was used to open the file, but not for WRITE or
APPEND. This restriction is necessary to avoid losing old
data in your file. Doing SETPOS clears EOF if it was set.
If you attempt to SETPOS beyond the end of file, EOF will be
either by the SETPOS itself, or by the next GET.
There are two older procedures available for random access,
USETI and USETO. They are probably not as useful, and are
more baldly machine-dependent. They are
USETI(file,integer-expression[,flag]), or
USETO(file,integer-expression). These set things up so the
next disk operation will use the <integer-expression>'th
block in the file. They are similar to the monitor USETI
and USETO, except that the buffer ring is cleared for you.
(A simple monitor USETI and USETO does not guarantee that
the next input will really come from the specified block.
The PASCAL runtimes take care of this.) USETI and USETO
cause the internal state variables to updated appropriately.
If it lands you in the middle of a logical block, things are
set appropriately. USETI(file,i) implies a GET(file), for
consistency with the rest of PASCAL. To suppress this GET
use a non-zero third argument, e.g. USETI(file,i,true).
[Note that BREAK and BREAKIN are no longer needed, or even
legal, with USETI and USETO.] USETI and USETO are really
part of the unbuffered code, and will not be implemented
until that is.
Note that if you specify a block number that doesn't exist
for a USETI or SETPOS, you will get EOF set. To clear do
CLREOF(<file>) to clear the PASCAL EOF indicator (and the
monitor's error bits). You can then do USETI to a more
reasonable block number and continue. (If you use SETPOS,
this clearing will be done automatically.)
3.12 APPEND
Occasionally one wishes to append new data onto the end of
an existing file. The monitor has facilities for doing this
without recopying the existing data. Proper use of these
facilities also allows one to append data to an append-only
file. The procedure APPEND implements this facility in
Page 34
PASCAL. It has exactly the same parameters as REWRITE. The
difference between it and REWRITE is that the file mentioned
must already exist and writing begins at the end of the
existing data. The arguments are exactly the same as with
REWRITE. APPEND may be used with any I/O mode, buffered or
unbuffered (as may REWRITE). If APPEND is used for a
non-disk device, it simply calls REWRITE.
For those who care about implementation details, APPEND
opens the file for updating, specifying a buffer header for
output only. If the mode is unbuffered, it just does an
appropriate USETO. If the mode is buffered, it first reads
the last block into the output buffer (by changing to mode
17 using SETSTS, doing unbuffered input, and then restoring
the requested mode). Then it uses the .rbsiz word to adjust
the buffer header so that further output goes into positions
not already filled. This method works whether the file is
append-only or not, although the reading in of the last
block is unnecessary for append-only files.
3.13 Miscellaneous I/O Functions
The following are provided for completeness. They will not
be useful for most people. Those that are not explained
below usually just do a monitor call with the same name.
See the Monitor Calls manual for such cases. They must be
declared external, as shown below, but they are built into
the PASCAL library. Note that the symbol FILE is legal in
the declaration of a procedure, as shown below. It will
match a file of any type. This sort of declaration, which
cancels some of the normal type checking, should be used
with great care.
Those functions and procedures that do not require EXTERN
declarations are listed below under Standard Functions and
Procedures.
PROCEDURE UPCASE(VAR F:FILE;MAP:BOOLEAN); EXTERN;
(* turn on or off mapping of lower case to equiv. upper *)
FUNCTION LSTREC(VAR F:FILE):INTEGER; EXTERN;
(* returns the length of the last record read or written *)
FUNCTION TO6(A:ALFA):INTEGER; EXTERN;
(* returns sixbit *)
PROCEDURE FROM6(SIXBIT:INTEGER;VAR A:ALFA); EXTERN;
(* sixbit to ASCII *)
FUNCTION CCLSW:BOOLEAN; EXTERN;
(* TRUE if program was started with RUN offset = 1 *)
PROCEDURE RNFILE(VAR RNDEV,RNNAM,RNPPN:INTEGER); EXTERN;
(* file from which program was run. sixbit integers *)
PROCEDURE RCLOSE(VAR F:FILE); EXTERN;
(* like CLOSE except does monitor RELEASE instead of
monitor CLOSE. If the file is internal, it is
deleted. *)
PROCEDURE SETSTS(VAR F:FILE;STATUS:INTGER); EXTERN;
PROCEDURE CLREOF(VAR F:FILE); EXTERN;
Page 35
(* clears PASCAL's EOF indicator. You must do this, and
possibly a SETSTS, if you want to proceed after an end
of file on MTA, etc. Sets EOF to false for input, true
for output. Clears the error indication, so the next
ERSTAT will return 0. *)
FUNCTION GETSTS(VAR F:FILE):INTEGER; EXTERN;
FUNCTION ERSTAT(VAR F:FILE):INTEGER; EXTERN;
(* If the user specified that he wanted I/O to continue in
spite of errors, this function must be used to check
for whether an error occurred. It will return 0 if no
error has happened, otherwise the error bits from a
GETSTS UUO. Note that errors bits are OR'ed into the
word that ERSTAT returns. So you see all errors since
the last time that errors were cleared by CLREOF. Note
that when an error happens, the bits are stored in the
place that this function looks at, and SETSTS is
immediately done to clear them. Thus to simply ignore
errors, you need do nothing other than specify that you
wish to process them, and never do anything else.
*)
PROCEDURE MTAPE(VAR F:FILE;OPERATION:INTEGER); EXTERN;
(* BREAK should be done before any MTAPE that repositions
the tape when output is being done, and BREAKIN should
be done after it when input is being done, assuming you
are in a buffered mode. Furthermore, if you open a
tape, and immediately issue a tape positioning command,
the initial get should probably be surpressed by using
the third parameter to the RESET. For example,
RESET(IFILE,'MTA0:',TRUE);
MTAPE(IFILE,...);
BREAKIN(IFILE);
READ(IFILE,....);
Note that to read more than one file from a tape you
will have to do SETSTS and CLREOF to clear the end of
file condition, as well as any necessary MTAPE and
BREAKIN. Or better, just reopen the file with RESET.
*)
FUNCTION INCHRW:CHAR; EXTERN;
PROCEDURE OUTCHR(C:CHAR); EXTERN;
FUNCTION INCHRS(VAR C:CHAR):BOOLEAN; EXTERN;
(* returns TRUE if it skips *)
PROCEDURE OUTSTR(????); EXTERN;
(* somehow you have to give it an ASCIZ string -
good luck! *)
FUNCTION INCHWL:CHAR; EXTERN;
FUNCTION INCHSL(VAR C:CHAR):BOOLEAN; EXTERN;
(* TRUE if it skips *)
FUNCTION GETLCH(LINE:INTEGER):INTEGER; EXTERN;
(* usually use -1 for line: your terminal *)
PROCEDURE SETLCH(STATUS:INTEGER); EXTERN;
FUNCTION RESCAN:BOOLEAN; EXTERN;
(* TRUE if there is something there *)
Page 36
PROCEDURE CLRBFI; EXTERN;
PROCEDURE CLRBFO; EXTERN;
FUNCTION SKPINC:BOOLEAN; EXTERN;
(* TRUE if it skips *)
FUNCTION SKPINL:BOOLEAN; EXTERN;
(* TRUE if it skips *)
PROCEDURE IONEOU(C:CHAR); EXTERN;
(* exactly like PUT8BITSTOTTY, which is built
into PASCAL *)
FUNCTION GETCHN:INTEGER; EXTERN;
(* Gets a free channel if you want to do your own I/O. *)
FUNCTION CURCHN(VAR F:FILE):INTEGER; EXTERN;
(* Returns the channel being used by FILE. This is junk
if FILE isn't currently open for I/O. *)
PROCEDURE RELCHN(CHANNEL:INTEGER); EXTERN;
(* Returns a channel you got with GETCHN. Don't do this
for a channel PASCAL is using. Use CLOSE to close a
PASCAL file and return its channel. *)
PROCEDURE ANALYS(VAR F:FILE); EXTERN;
(* If an error occurred in openning or processing this file,
prints an official-looking error message. No effect if no
error occurred, or if the file is connected to a string with
STRSET or STRWRITE. *)
Beware that programs using these things are of course not
transportable to machines other than the DEC10!!
3.14 Including other source files in a program
When one is doing a big projects, there are often several
programs that use the same set of type declarations,
external procedure declarations, etc. To help maintain
consistency, one would like to be able to put these
declarations in a single file and have several programs
access that file. This is possible with the file inclusion
feature. The syntax of PASCAL has been extended to allow
one or more requests of the form INCLUDE '<file spec>'; as
the first part (i.e. before the CONST part) of any block.
This causes the specified file to be read in at that point.
The file may contain only CONST, TYPE, and external
PROCEDURE declarations. The included file follows the
normal PASCAL syntax for declarations, except that a period
is required after the last declaration. Nothing in the file
after the period is read. This construct functions as if
the declarations in the file had been included in the text
of the block where the FILE statement appears. More than
one file may be listed in a single such request, separated
by commas. Or several INCLUDE statements may be used, one
after the other.
Note that the symbol INCLUDE is now a reserved word.
3.15 The structure of a PASCAL program
Page 37
Some users will need to know the exact structure of a PASCAL
program in memory. First we will describe the structure of
a program on VM systems (i.e. everything except a KA-10).
PASCAL produces two-segment programs, which are potentially
sharable. Thus at the start of the program, the high
segment contains all of the code and certain constants, and
the low segment contains global data. There are three other
data areas which are created during execution of the
program: the stack, the heap, and I/O buffers. I/O buffers
are created by the monitor, under control of the runtimes.
They are located immediately above the initial data area in
the low segment. .JBFF always points to the next location
above the I/O buffers. Since PASCAL uses the conventional
interpretation of .JBFF, you may call MACRO routines that
get working storage at .JBFF. However, unless you are using
the KA-10 version, you must make certain that these routines
never use a CORE UUO to contract core, since the stack and
heap are allocated with the PAGE. UUO, and the core UUO
will deallocate this memory. (The CORE UUO may be used
freely to expand memory, just not to contract it.) The heap
contains all space allocated by the NEW function. It is
located immediately below address 400000B, and expands
downwards. The stack contains parameters, return address
for routines calls, and all local variables for procedures.
The stack is allocated in pages located ABOVE the high
segment. Since this storage is created with the PAGE. UUO,
it is officially considered part of the low segment, and is
writeable.
In the KA-10 implementation, the stack and heap are kept in
low core, below .JBFF. They are allocated after any
variable areas produced by the compiler, and .JBFF is moved
after them. The stack starts at the bottom end of this
piece of core and grows upwards. The heap starts at the top
end and grows downwards. If the stack and heap ever meet,
the program is stopped with a fatal error. I/O buffers are
allocated at .JBFF, as usual. In this case, that is above
the stack and heap. The area for the stack and heap is
allocated at program startup time, based upon parameters
assembled into the program.
The entry code compiled into every PASCAL main program does
some things that you may find useful to know about. First,
it has PORTAL instructions at the starting address and at
the next address. This means that a PASCAL program may be
made execute-only, and be started either normally or with a
run offset of 1. Second, there is a global variable %CCLSW,
which is set to 0 if the program is entered normally, and to
1 if it is entered with a run offset of 1. Third, the
accumulators 0, 7, and 11B are stored in locations %RNNAM,
%RNPPN, and %RNDEV. These names are defined as global
symbols.
Page 38
It should be possible to control-C a PASCAL program and
restart it. However, the user should be aware that global
variables will not be reinitialized in this case. (In
particular INITPROCEDURE's will NOT be done again, as they
are not really executable code at all.)
4. PASCAL Debug System (PASDDT)
A PASCAL program may be run with the PASCAL Debug System by
using the monitor command DEBUG instead of EXECUTE.
(Successful debugging also requires that the program be
assembled with /DEBUG, but this is on by default.) The
system can be used to set breakpoints at specified line
numbers. When a breakpoint is encountered, program
execution is suspended and variables (using normal PASCAL
notation) may be examined and new values assigned to them.
Also additional breakpoints may be set or breakpoints may be
cleared. It is helpful to have a listing of the program
available as the system is line number oriented.
Should you need to run LINK explicitly, rather than using
the monitor DEBUG command, PASDDT is included by loading the
file SYS:PASDDT.
4.1 Commands
The commands described here can be given when the system
enters a breakpoint. When the program is executed an
initial breakpoint will be entered before the main program
begins. This will be shown by a message
> STOP AT MAIN BEGIN
>
Additional breakpoints are set by
STOP <line>
where <line> is of the form line#/page# or just line# which
is equivalent to line# on the current page. An example is
120/3, line 120 on page 3. A maximum of 20 breakpoints may
be set.
PASDDT keeps track of the "current line". The current line
is the one most recently printed out. (In the case of
printouts showing a range, it is the first one in the
printout.) This line can be referred to by a simple star (*)
Hence "STOP *" will be equivalent to "STOP 3/5" if line 3 on
page 5 is the current line. If you type a line number with
no page number, the current page is supplied. So if the
current line is 3/5, then "STOP 100" referrs to 100/5. To
find out what the current line is, type
* =
Page 39
The breakpoint is cleared by
STOP NOT <line>
STOP NOT ALL will clear all of them. The breakpoints set
may be listed by
STOP LIST
Variables may be examined by the command
<variable> =
<variable> may be any variable as given by the PASCAL
definition (except files). In particular it may be just a
component of a structured type, or the whole structure
itself. In the case of arrays, adjacent elements that are
identical are displayed in a compressed form.
A new value may be assigned to a varible by
<variable> := <variable or constant>
The assignment follows the usual type rules of PASCAL.
PASDDT has access to your source file (assuming that it is
still there when you get around to running the program).
Whenever you reach a breakpoint, the portion of your source
file around the breakpoint will be displayed. Often it is
useful to look at other parts of your program, in order to
decide where to place breakpoints, or for other reasons. To
look at your program, there are two commands:
TYPE <line> [<line>]
FIND [<count>] [<string>]
TYPE allows you to type a line or range of lines in the
currently open file. (Use OPEN to change which file you are
talking about, as described below.) FIND allows you to
search for any text string in the current open program.
E.g.
>> find 'foo'
will look for the next appearance of foo in your file. To
find the second appearance of foo, use
>> find 2 'foo'
Note that the FIND search starts at the line after the
current line (.).
PASDDT can be used to follow execution of your program line
by line. This is called "single stepping". Once you start
this mode of execution, each time you hit the carriage
Page 40
return key, one line of your program will be executed. The
commands relevant to single-stepping are:
STEP
STEP causes the next line of your program to be executed.
Since you often want to do this for many lines, it is rather
inconvenient to type the word "STEP" for each line. Thus
once you have done one step command, PASDDT enters a special
mode where a simple <CR> will cause the next line to be
executed.
<cr> - do one line in single-step mode
This mode is announced by changing the prompt from the usual
">>" to "S>". Note that all the normal PASDDT commands are
available as usual. The main difference that S> mode makes
is that <CR> is available as an abbreviation for STEP.
You get out of single step mode by doing a normal END, i.e.
by proceeding your program in the normal way.
One other command is available in single step mode:
<esc> - continue until end of procedure
When you are single-stepping and come to a procedure call,
the single-stepper will show you everything that goes on
within the procedure. Sometimes you really don't want to
see the inner workings of the procedure. You just want to
continue watching the program from the point where the
procedure returns. An <esc> (sometimes labelled <alt>) in
single-step mode will cause the stepper to finish the
current procedure silently. The next time you hear from the
debugger will be when the procedure exits (unless of course
you have placed a breakpoint within the procedure).
We advise all users to experiment with the STEP command,
since single-stepping is the single most effective debugging
tool we know.
The current active call sequence of procedures and functions
is obtained by
TRACE
The names of the procedures and functions together with
their line numbers are printed in reverse order of their
activation. TRACE may optionally be followed by a number,
which will be the number of levels for which information is
printed.
You can display the values of all variables current active
in the program by using the command
Page 41
STACKDUMP
This will give the same information as TRACE, and
additionally at each level display the names and values of
all local variables. As with TRACE, you may follow
STACKDUMP by a number, and only that many levels will be
displayed. You may also follow it with a filename in
quotes. The information will be put in that file, instead
of dumped to your terminal.
Program execution is continued by the command
END
The program will run until another breakpoint is
encountered. The breakpoint is announced by
> STOP AT <line>
>
Should you have more than one module (presumably because you
have loaded both a main program and a file of external
procedures), special care is required. At any given moment
only one module is accessible to the user. That means that
attempts to refer to variables or line numbers in another
module will meet with errors. To change modules use the
command
OPEN <module>
The module name is the name in the program statement for the
corresponding file. If no program statement occurs, it is
the name of the .REL file. Whenever PASDDT is entered, it
will tell you the name of the module that is open initially.
In the case of a break, the module in which the broken line
occurs is openned.
Sometimes there will be variables of the same name at
several levels. In this case you may find it impossible to
refer to a variable at a higher lexical level than the one
where the break occurs. The command
OPEN <depth> <module>
will set the context in which names are interpreted to any
depth desired. The depth you type is the name as shown on
TRACE or STACKDUMP.
If you want to stop debugging, the command
QUIT
is sometimes useful. It is somewhat cleaner than control
C-ing out of the debugger, as it closes all files and does
Page 42
other normal cleanup. Note that if you QUIT, partially
written files are closed, and thus made to exist. Control C
will not make such files visible.
You can control the verbosity of PASDDT with the command
SHOW <integer>
This controls the number of source lines shown when you
enter a break. 0 is legal if you don't want to see any.
4.2 Asynchronous Interrupt
If a program goes into an infinite loop it may be aborted by
^C^C. The monitor command DDT followed by a carriage-return
will enter the PASCAL Debug System. This interrupt is
announced with the message
> STOP BY DDT COMMAND
> STOP IN <line1>:<line2>
>
If you happened to stop the program when it is in the
runtimes, you will get an invalid result, probably line 0.
However the other functions of PASDDT should still work in
this case.
5. Standard and External Procedures and Functions
5.1 Standard Procedures and Functions
The following standard procedures and functions (described
in the Revised PASCAL Report) are implemented.
Standard Functions Standard Procedures
ABS GET (See 2.5 and 3.8.10)
SQR PUT (See 3.8.10)
ODD RESET (See 2.3 and 3.8)
SUCC REWRITE (See 2.3 and 3.8)
PRED NEW
ORD READ
CHR READLN (See 2.6)
TRUNC WRITE (See 2.4)
ROUND WRITELN (See 2.4)
EOLN PAGE
EOF PACK
SIN UNPACK
COS
EXP
LN
SQRT
ARCTAN
Page 43
Additional mathematical functions are available:
ARCSIN SIND
ARCCOS COSD
SINH LOG
COSH
TANH
The following functions may be used to simulate the missing
** operator. They must be declared EXTERN.
FUNCTION POWER(X,Y:REAL):REAL; EXTERN; - X ** Y
FUNCTION IPOWER(I,J:INTEGER):INTEGER;EXTERN - I **
J
FUNCTION MPOWER(X:REAL;I:INTEGER):REAL;EXTERN - X
** I
Additional standard functions:
CURPOS(file) returns the current position in a file.
See section 3.11. Only valid for files on random
access device. (type integer)
DATE result is a PACKED ARRAY [1..9] OF CHAR. The date
is returned in the form 'DD-Mmm-YY'.
RANDOM(ignored) Argument is an integer, which is
ignored. Result is a real number in the interval
0.0 .. 1.0
RECSIZE(file) returns the record size of the file. One
may also specify a particular variant whose length
is to be returned. See section 3.8.10 for
details. (type integer)
RUNTIME elapsed CPU time in msec (type integer)
TIME current time in msec (type integer)
Additional standard procedures:
APPEND(file,name,...). Like REWRITE, but extends an
existing file. See section 3.12.
BREAK(file). Forces out the output buffer of a file
and starts a new block. Should be used before
magtape positioning, and to force out messages to
terminals. (However it is not needed for TTY.)
BREAKIN(file,noget). Clears the input buffer ring of a
file. Must be used after magtape positioning for
buffered input. Starts a new logical block. If
noget is omitted or zero (FALSE), a GET is done on
the file after the buffer ring is cleared.
CALLI(code,LH,RH,value,success). Arbitrary monitor
call. See section 3.2.
CLOSE(file,bits). Close file and release its channel.
See section 3.6.
DELETE(file). Delete file. See section 3.9.
DISPOSE(pointer,variant,...). Return a record to the
Page 44
heap. See section 1.2. (Some editions of Jensen
and Wirth include this as a standard procedure.)
DISMISS(file). Abort creation of a file. See section
3.6.
DUMPIN(file,var,length). Read data into arbitrary
place in dump mode. See section 3.10.
DUMPOUT(file,var,length). Write data from arbitrary
place in dump mode. See section 3.10.
GETINDEX(file,index). If file is open on a string
(STRSET or STRWRITE), sets index to current index
into the string. (See section 3.1.)
GETLINENR(file,lineno). Lineno must be a packed array
of char. It is set to the last line number seen
in the file. If no line numbers have been seen
'-----' is returned. ' ' is returned for a
page mark. If file is omitted, INPUT is assumed.
MARK(index). Save state of the heap. See 3.7.
PUTX(file). Rewrite record in update mode. See 3.10.
RELEASE(index). Restore saved state of the heap. See
3.7.
RENAME(file,name,...). Rename an open file. See 3.9.
SETPOS(file,position). Move in random access file.
See 3.11.
STRSET(file,array,...). Open input file on array. See
3.1.
STRSET(file,array,...). Open output file on array.
See 3.1.
UPDATE(file,name,...). Open random access file for
revising in place. See section 3.10.
USETI(file,block,noget). Low level primitive for
positioning random access file for input. See
section 3.11.
USETO(file,block). Low level primitie for positioning
random access file for output. See section 3.11.
Although it is not exactly a procedure or function, some
explanation should be given of the MOD operator. X MOD Y is
the remainder after dividing X by Y, using integer division.
The sign of the result is the same as the sign of X (unless
the result is zero, of course). Note that this is a
different definition than the one used by mathematicians.
For them X MOD Y is always between 0 and Y-1. Here it may
be between -(Y-1) and +(Y-1), depending upon the sign of X.
This implementation is used for consistency with the Cyber
implementation, which is the semi-official standard. Note
that SAIL (and some other widely used languages) also use
this perverted definition of MOD.
5.2 External Procedures and Functions
A procedure or function heading may be followed by the word
EXTERN. This indicates to the compiler that the routine
will be supplied at load time. In addition it may be
specified that the routine is a PASCAL, FORTRAN, ALGOL or
COBOL routine. PASCAL is assumed if no language is
Page 45
specified. The language symbol determines how the
parameters are passed to the external routine. The
relocatable file also contains information to direct the
loader to search the corresponding library on SYS:.
Example: PROCEDURE TAKE(VAR X,Y: INTEGER); EXTERN
FORTRAN;
The PASCAL compiler can deal with two kinds of files: main
programs and files of external procedures. A main program
contains a single program with procedures local to it.
There must be exactly one main program involved in any load
(i.e. in one EXEC command). Any procedures not present in
the main program must be declared EXTERN, as explained
above. They must then be defined in a file of external
procedures.
A file of external procedures has the following differences
from a main program: (1) There is no top level code. The
period follows the last top level subroutine. For example:
var i,j:integer;
procedure a;
begin i:=1 end;
procedure b;
var y:integer;
begin y:=1 end.
In a main program, there would be top level code after
procedure B. (2) The top level procedures, A and B in the
above example (but not any procedures defined within A or
B), have their names declared in a special way. This makes
them accessible to other programs. Note that only the first
six characters of the name are significant to other programs
that access these procedures as EXTERN. (3) A file of
external procedures must either have a comment of the form
(*$M-*) at the beginning, or be compiled /NOMAIN. (These
both do the same thing.)
You may combine several .REL files containing external
procedures to form a library. If you want to search this in
library search mode, it will be necessary to specify entry
points for each module. Each source file will compile into
a single module. The module name will be the program name
specified in the PROGRAM statement, if there is one,
otherwise the file name. If you do nothing special, that
module name will also be used as the only entry for the
module. If there is no top level procedure with the same
name, that name will be assigned as an alternate name for
the first procedure in the file. To get more than one entry
point, you must use a special form of the PROGRAM statement,
e.g.
PROGRAM TEST,A,B;
Page 46
for the above example. This declares TEST as the module
name, and A and B as the entry points. Usually you should
list all of the top level procedures as entry points,
although this is not required. Note that these entry points
are only needed for library search mode. Even without this
special PROGRAM statement the procedures A and B could be
accessed as EXTERN procedures by a separate main program.
Note that the normal form of program statement, e.g.
PROGRAM TEST (A, B);, is illegal for a file of external
procedures. All files that are to be initialized at the
beginning of the program must be declared in the program
statement in the main program. The form that declares only
the module name, e.g. PROGRAM TEST;, is legal, however.
It is possible for one file of external procedures to call
procedures defined in another file of external procedures.
As usual, they must be declared as EXTERN in each file where
they are to be called.
Assume the files TEST.REL, AUX1.REL, and AUX2.REL are to be
loaded, along with a routine from the library
NEW:ALGLIB.REL. Execution is accomplished by:
EXEC TEST,AUX1,AUX2,NEW:ALGLIB/LIB
Note that this command would cause any of the programs that
had not been compiled to be compiled.
6. Miscellaneous
6.1 Implementation Restrictions
a) A maximum of 20 labels is permitted in any one procedure.
(This is an assembly parameter. The whole restriction may
be removed easily, at the cost of some extra local fixups in
the .REL file.) This includes both labels declared in the
LABEL section and those not so declared. (Labels need be
declared only if they will be the object of a non-local
goto.)
b) Printer control characters are not available. A new page
is started by a call to the standard procedure PAGE.
c) Procedures and functions may be passed as parameters to
procedures and functions, as described in the Revised
Report. We have not modified the syntax to allow
declaration of the arguments to such parametric
procedures/functions. (Prof. Nagel's version contains such
a modification.) Also, note that when a parametric
procedure/function is called, all of the arguments passed to
it must fit in the accumulators. Normally this allows 5
arguments, although certain arrays count as 2 arguments, and
functions allow one extra argument. An appropriate error
Page 47
message is given if this constraint is violated.
d) A maximum of 1200 words of code may be generated for any
procedure or function. Since /DEBUG and /CHECK produce more
code, it is normal to run into this limit when /DEBUG is
turned on in programs that compile correctly for /NODEBUG.
The error message "Too many cases in CASE statement" is
usually caused by a procedure or function that is too long,
rather than by too many cases. (There is no separate limit
to the number of cases in a CASE statement.) The maximum
number of words is an assembly parameter, so it may be
expanded easily, if the compiler is recompiled.
e) Only comparisons described in the PASCAL manual can be
done. There were serious problems with the earlier attempt
to allow comparison of arbitrary records and arrays.
f) Sets may only be defined on types or subranges of types
having 72 or fewer members. With subranges of integers the
set may only include 0 to 71. With enumerated types it may
include only the first 72 members of the enumeration.
Special provisions are made to allow sets of CHAR. The
problem is that there are 128 possible ASCII characters.
This problem is "solved" by treating certain characters as
equivalent. In particular, lower case letters are treated
as equivalent to the corresponding upper case letter. And
all control characters except for the tab are treated as
equivalent. Thus ['a'] is exactly the same set as ['A'].
(One of those is lower case and the other upper case.)
Similarly 'a' in ['A'] will succeed. And ['X'] is the same
set as ['B'].
g) WRITE(TTY,X,Y) actually writes to the file TTYOUTPUT.
This mapping of TTY into TTYOUTPUT occurs at compile time.
So if you pass the file TTY to a procedure as parameter F,
WRITE(F,X,Y) is not transformed into WRITE(TTY,X,Y). It is
not clear whether this is a bug or not.
h) This compiler attempts to check that assignments to
subrange variables are within the subrange. It is possible
to fool this test by using VAR parameters. These problems
cannot be overcome unless there is some way for the compiler
to tell which VAR parameters are intended as inputs to the
procedure and which as outputs.
i) The contents of unused bits in packed arrays and records
is undefined. This should not cause trouble, except in
programs the play fast and loose with variant records, or
programs that pass arrays of type PACKED ARRAY OF CHAR to
Fortran programs. Many Fortran programmers will use integer
comparisons on character data, thus requiring the low order
bit in the word to be zero. The code compiled in Pascal to
compare PACKED ARRAY OF CHAR variables ignores the low order
bit, so this does not cause a problem in Pascal. If you
require unused fields to be zero in all cases, you can set
Page 48
/ZERO or (*$Z+*).
j) Only the first 10 characters of identifiers are examined,
so all identifiers must be unique to their first 10
characters. Note that the Revised Report only requires the
implementation to look at the first 8.
k) All of the entry points in the runtime library are
effectively reserved external names. That is, if you use
one of these names either as your program name (in the
PROGRAM statement) or as the name of a procedure in a file
of external procedures, disaster may result. Any name whose
first six characters is the same as one of these names will
cause the problem. You can sometimes get away with
violating this rule if your program does not use any of the
features of Pascal which cause the particular runtime
routine involved to be invoked. As of the time when this
document was prepared, the following were the entry point
names. For an up to date list, use the command
"TTY:=PASLIB/POINTS" to MAKLIB: ANALYS, APPEND, BREAK,
BREAKI, CLOFIL, CORERR, CURCHN, DCORER, DUMPIN, DUMPOU, END,
GET, GETCH, GETCHN, GETLN, GETX., INTREA, INXERR, LSTNEW,
NEW, NEWBND, NEWCL., PASIM., PASIN., PTRER., PUT, PUTLN,
PUTPG, PUTX, QUIT, READC, READI, READPS, READR, READUS,
RELCHN, RENAME, RESDEV, RESETF, REWRIT, SRERR, TRUNC,
TTYOPN, UPDATE, USETIN, USETOU, WRITEC, WRTBOL, WRTHEX,
WRTINT, WRTOCT, WRTPST, WRTREA, WRTUST, DEBUG, PARSE,
CLRBFI, CLRBFO, GETLCH, INCHRS, INCHRW, INCHSL, INCHWL,
IONEOU, OUTCHR, OUTSTR, RESCAN, SETLCH, SKPINC, SKPINL,
CCLSW, CLREOF, ERSTAT, FROM6, GETSTS, MTAPE, RCLOSE, RNFILE,
SETSTS, TO6, UPCASE, GETFN., BLKLFT, BUFLFT, CURPOS, CURREC,
GETSIX, GETVAR, LRCSIZ, LSTPOS, NEXTBL, RECSIZ, SETPOS,
SETREC, SIXFRE, SPACEL, VARFRE, .STCHM
l) The compiler does not enforce the restriction that a FOR
loop body may not change the controlled variable nor the
expression used for the start and end tests. The following
two statements are illegal, but will compile under this
compiler: FOR I := 1 TO N DO I := I+1; FOR I := 1 to N DO
N := N + 1; The first of these will do every other value of
I. The second will be an infinite loop. According to the
Revised Report, they are both illegal statements.
6.2 Use of DDT
It is possible to use regular DDT to debug a PASCAL program.
To do so, use the monitor DEBUG command with the switch /DDT
after the first file name. If you run LINK explicitly, type
/DEBUG as the first command, as usual.
It is also possible to have both PASDDT and DDT in core at
the same time. To do so, you should load the file
SYS:PASDEB with your program, e.g. "EXEC
SYS:PASDEB.REL,PROG.PAS". PASDEB has the appropriate
garbage in it to load the right files in the right order.
Page 49
When loading is finished, DDT will be started. You may
examine things and set breaks using DDT. If you decide you
will want any breaks using PASDDT, you should then use the
command "PASDEB$G" in DDT. This will set things up so when
you start your program you will get the usual "Stop at main
BEGIN". To start your program type "$G". By the way, be
sure not to use the DEBUG command when loading PASDEB, as
you will get two copies of DDT!
In DDT, you will find that there are a few symbols defined
for you. The beginning of your main program is defined as a
global symbol. Each procedure has up to three symbols
defined for it. Assume that your procedure is called NAME.
Then we have
NAME the first part of the procedure proper.
This is an appropriate place to put a DDT break
point.
NAME. the first instruction of a sequence of code
used to adjust the static display pointer. It is
located before NAME Most procedure calls are to
NAME.+<some integer>, rather than to NAME
NAME% the first location of a block of byte
pointers associated with this procedure. This is
located before NAME.
6.3 Interfacing to external procedures in MACRO
This section discusses the structure of MACRO routines
designed to be called from as PASCAL program. Such routines
will require a declaration within the PASCAL program, with
EXTERN used in place of the body. EXTERN causes the
compiler to expect a routine that uses the PASCAL calling
conventions, so those will be discussed here. Should you
prefer to use the Fortran-10 calling conventions, the
routine should be declared EXTERN FORTRAN.
The calling conventions are similar for both procedures and
functions. The only difference is that functions return
values, and procedures don't. In both cases, the arguments
are put in accumulators 2 through 6. There is a way to pass
more parameters than will fit in these accumulators, but it
is fairly complex to explain. Should you need to do this,
you are probably best to look at the code produced by the
compiler (using /OBJECT). What is put in the accumulators
is determined as follows:
by value, one word - the value in one accumulator
by value, two words - the value in two successive
accumulators
by value, more than two words - address of object in
one accumulator
by reference (VAR) - address of object in one
accumulator
Page 50
Your routine may use the accumulators freely, except for 15,
16, and 17.
15 - the highest address available in the pushdown
list. See entry for 17. This value should be
unchanged on exit from your routine, unless you
call corerr.
16 - pointer to the base of the local variable area.
This is in the stack below the current value of
17. All local variables of the calling routine
may be accessed as positive offsets off 16. To
find the offsets you will have to look at the
object code, however. This value should be
unchanged on exit from your routine.
17 - pointer to the top of the stack. You may use it
in pushj and push. However, beware that you are
only guaranteed 40 (octal) locations on it. This
is enough to call any of the PASCAL runtimes. But
if you will be using it much, use the following
code. Note that the left half of 17 is not your
usual pdl left half. In particular, you will not
get a PDL overflow error if you try to use too
much. Instead you will get ill mem ref, as the
stack is at the top of core.
caig 15,xx(17) ;xx = stack space needed
jsp 1,corerr## ;core allocation routine
If your routine is to be called as a function, it should
move the result to 1(p). [That's right, folks, one above
the top of stack.]
You may call any PASCAL runtime routine with a simple pushj
17,. You may call any normal PASCAL-compiled routine with a
pushj 17, but you should push a dummy argument on the stack
first, as pascal routines garbage -1(17).
6.4 Special linkage conventions for hackers
The following three identifiers function syntactically as if
they were predeclared types. However they are only legal
when used to describe parameters of EXTERN procedures. Thus
they are a convenience for those brave souls who are trying
to add more runtimes but do not want to have to modify the
compiler.
FILE - a parameter declared as FILE will match a file
of any type. This is necessary for procedures
such as CLOSE, RENAME, etc., which one obviously
wants to work for files of all types.
STRING - a parameter declared as STRING will match a
packed array of CHAR of any length. This is used
for the file name argument in RESET, REWRITE, etc.
It actually puts data into two registers. The
first gets the address of the array. The second
gets its length in characters. This type of
parameter only works with Pascal procedures. You
can't pass it to Fortran, Cobol, or Algol. No
Page 51
error message will be generated if you try, but
the results are garbage.
POINTER - a parameter declared as POINTER will match a
pointer of any kind. It is used for procedures
such as NEW, which must work for pointers to any
kind of structure. It also puts data into two
registers. The first gets the value of the
pointer (or its address if VAR is used). The
second gets the size (in words) of the structure
that the pointer points to. This type of
parameter only works with Pascal procedures. You
can't pass it to Fortran, Cobol, or Algol. No
error message will be generated if you try, but
the results are garbage.
Use of these things is strongly discouraged except by Pascal
maintainers, who are assumed to understand what is going on.
References
(1) N. Wirth. The Programming Language PASCAL (Revised
Report) Bericht Nr. 5, Berichte der Fachgruppe
Computer-Wissenschaften, ETH Zurich, November 1972
(2) K. Jensen, N. Wirth. PASCAL - User Manual and Report.
Springer Verlag, Berlin, Heidelberg, New York, 1974.