perm filename ADSAIL.DOC[CMU,AIL] blob
sn#091929 filedate 1974-03-19 generic text, type T, neo UTF8
⊗Q 7 ⊗S
⊗R 11 ⊗T
CMU SAIL UPDATE
March 19, 1974
INTRODUCTION
The following document describes the changes that have happened to SAIL
since the publishing of the CMU Manual in June 1973. References are by
section number in that CMU manual, although, with few exceptions, the
CMU and Stanford manuals have identical numbering. As the Stanford
manual is more recent than CMU's, this document will overlap somewhat
with the former.
The reader may also want to refer to the following documents, which are
usually kept updated. They are on [A701SA00] on the CMU-10/B.
MACLIE.WRU A summary of commonly made errors when using macros
and what to do about them.
TUTOR.DOC An introduction to LEAP.
LEAP.WRU A detailed description of the runtime environment of
LEAP for the hardy few who want to interface to LEAP
in assembly language.
LIES This file contains known mistakes in the Stanford
Manual.
CMU Sail Update March 19, 1974
TABLE OF CONTENTS
SECTION PAGE
PREFACE
CHANGES IN THE LANGUAGE . . . . . . . . 1
ALGOL DECLARATIONS - 2
EXPRESSIONS IN REQUIRES - 2.1 . . . . . . 1
INITIALIZATION PHASES - 2.4 . . . . . . . 1
ALMOST INEXHAUSTIBLE STRING SPACE - 2.4 . . . 1
ALGOL EXPRESSIONS - 4
ASH - 4.3 . . . . . . . . . . . . . 3
EXPONENTIATION - 4.3 . . . . . . . . . 3
I/O ROUTINES - 7
OPEN - 7.2 . . . . . . . . . . . . . 3
OPEN: ERROR HANDLING - 7.2 . . . . . . . 3
RELEASE - 7.2 . . . . . . . . . . . . 4
CHNCDB - 7.2 . . . . . . . . . . . . 4
LOWER/UPPER CASE CONVERSION - 7.3 . . . . . 4
SETPL - 7.4 . . . . . . . . . . . . 4
SETSTS/GETSTS - 7.4 . . . . . . . . . . 5
INOUT - 7.4 . . . . . . . . . . . . 5
NEW MTAPE OPTIONS - 7.4 . . . . . . . . 5
INCHWL - 7.5 . . . . . . . . . . . . 5
EXECUTION TIME ROUTINES - 8
CVOS - 8.1 . . . . . . . . . . . . . 6
USERERR - 8.3 . . . . . . . . . . . . 6
ARRCLR - 8.5 . . . . . . . . . . . . 6
FILEINFO - 8.5 . . . . . . . . . . . 7
NUMERICAL ROUTINES - 8a
THE ROUTINES - 8a.1 . . . . . . . . . . 7
OVERFLOW/UNDERFLOW - 8a.2 . . . . . . . . 8
ENTRY POINTS - 8a.3 . . . . . . . . . . 9
MACROS AND CONDITIONAL COMPILATION - 9
DEFINE - 9.3 . . . . . . . . . . . . 9
REDEFINE - 9.3 . . . . . . . . . . . 9
DEFINE/REDEFINE - 9.3 . . . . . . . . . 9
EVALDEFINE - 9.3 . . . . . . . . . . . 9
EVALREDEFINE - 9.3 . . . . . . . . . 10
NOMAC - 9.3 . . . . . . . . . . . 10
ASSIGNC - 9.3 . . . . . . . . . . . 10
CVPS - 9.4 . . . . . . . . . . . . 10
i
CMU Sail Update March 19, 1974
IFC/IFCR - 9.5 . . . . . . . . . . 10
LEAP STATEMENTS - 11
BRACKETED TRIPLES - 11.4 . . . . . . . 11
PROCESSES - 13
SPROUT APPLY - 13.3 . . . . . . . . . 11
SPROUT_DEFAULTS - 13.3 . . . . . . . . 11
SUSPEND - 13.3 . . . . . . . . . . 12
FAIL AND SUCCEED - 13.3 . . . . . . . 13
PROCEDURE VARIABLES - 15
ARG_LIST - 15.2 . . . . . . . . . . 13
USING SAIL - 19
SWITCH F - 19.3 . . . . . . . . . . 14
CONDITIONAL COMPILATION - 19.3 . . . . . 14
DEBUGGING SAIL PROGRAMS - 20
ERROR MODES - 20.1 . . . . . . . . . 14
USER ERROR PROCEDURES - 20.2 . . . . . . 15
APPENDICES
APPENDIX 4 . . . . . . . . . . . . 16
APPENDIX 11 . . . . . . . . . . . 16
APPENDIX 15 . . . . . . . . . . . 16
ii
CMU Sail Update March 19, 1974
PREFACE
CHANGES IN THE LANGUAGE
Number 2., concerning the effect of DEFINE, should be ignored.
ALGOL DECLARATIONS - 2
EXPRESSIONS IN REQUIRES - 2.1
Previously, all REQUIRE constructs had to have only constants in
them. Now SAIL allows compile time expressions as well. See about
compile time expressions in 9.3 in the manual.
INITIALIZATION PHASES - 2.4
User initializations are now done in successive phases, with all
initializations required for one phase being done before initializations
required for the next phase.
Syntax:
REQUIRE <procid> INITIALIZATION;
REQUIRE <procid> INITIALIZATION [<phase no>];
where <phase no> is an integer constant.
Semantics:
<phase no> specifies the number of the user initialization
phase. If it is left out, then 1 is used. Currently, there are three
phases, numbered 0, 1, and 2. If the demand is great enough, additional
phases may be added later. (Note for assembly language hackers:
internally, user phases are numbered '400000, '400001, etc.)
ALMOST INEXHAUSTIBLE STRING SPACE - 2.4
The string garbage collector has been modified to expand string
space (using discontiguous blocks) whenever necessary to satisfy the
demand for places to put strings. To take advantage of this feature,
one need not change his programs.
1
CMU Sail Update March 19, 1974
Here are some points which might be of interest, however:
1) Although we are going to provide user control over all size
parameters eventually, currently only the initial string space size
is settable by the user, either via REQUIRE or the ALLOC sequence,
as before. The size of each string space increment will be the same
as the original size, which need not be monstrous any more unless
you know that all runs of your program will need a monstrous string
space anyhow. The threshold (see below) for expanding will be set
at 1/8 the string space size (increment size).
2) One can, in his program, modify these values independently, if he is
willing to use the USERCON function, and to follow this format:
TABLE ENTRY NAME VALUE
STINCR lh: number of chars. in increment
rh: number of words in increment + 4
STREQD lh: number of chars. in threshold
rh: number of words in threshold.
3) The threshold. After garbage collection, let us say that M-1
discontiguous string spaces are full, and the M'th has N free
characters in it (available for new strings). The garbage collector
was called because some routine wanted to create a string R
characters long, and there were not that many available (free).
After garbage collection, the new algorithm requires that N be
greater than R+LH(STREQD). If it is not, expansion takes place (to
M+1 spaces), to satisfy this requirement. In other words, if STREQD
is 1/8 the size of the current space, that space will not be allowed
to become more than about 7/8 full. This helps avoid frequent,
nearly useless calls on the garbage collector when space is about
gone. All but the current space are allowed to become as full as
possible, however.
4) New statistics are maintained by the garbage collector. Soon there
will be a built-in routine you can use to print them. For now, you
may look at them using USERCON, although this document does not say
what they are. In order to activate timing of the garbage collector
(slows it down), set SGCTIME in the user table to -1.
5) Future plans. The new structure not only allows expansion of string
space, it also will allow for partial garbage collections (no
visible benefits except increased speed, since a partial collection
will be almost as effective as a complete one, and much faster), and
the ability to move string space blocks, in order to compact memory.
Push on your local representative to get these things done.
2
CMU Sail Update March 19, 1974
Note: no single string can be larger than a block of string
space, or you will get a non-recoverable error of "STRING SPACE
EXPANSION: REQUEST TOO BIG".
ALGOL EXPRESSIONS - 4
ASH - 4.3
ASH, the arithmetic shift, has been implemented. It takes two
arguments, and forces both to integer before producing its integer
result. The effect of A ASH B is the same as A*2↑B.
EXPONENTIATION - 4.3
A↑B is always real, unless B is a positive integer constant (or
compile-time expression). This is particularly likely to cause problems
when an exponent is being given to some routine that is expecting an
integer. Instead, store the result of the exponent expression into an
integer variable, and feed that variable to the routine.
I/O ROUTINES - 7
OPEN - 7.2
Under EOF (2): no appendix has anything to do with I/O errors
or mode enablings. See the DEC monitor manual instead.
OPEN: ERROR HANDLING - 7.2
There have been changes to error handling in OPEN:
1) The appearance of the message "invalid device name for OPEN"
is now also controlled by the value of the EOF variable on entry.
2) If the device is unavailable, the choice is now to try again
or go on without, rather than try again or "blow up". If going on
without, the EOF variable is set non-zero to indicate lack of success.
3
CMU Sail Update March 19, 1974
RELEASE - 7.2
RELEASE now takes an optional second argument, the CLOSE inhibit
bits. These are described in the DEC monitor manual. They are
defaulted to zero when not specified so that old programs which did not
specify them will work as before.
CHNCDB - 7.2
val←CHNCDB(channel)
This integer procedure returns a pointer to the three word block
used to open the specified channel. It is provided for the benefit of
assembly language procedures that may want to do I/O inside some fast
inner loop, but which may want to live in a SAIL core image & use the
SAIL OPEN, etc.
LOWER/UPPER CASE CONVERSION - 7.3
Facilities have been added that convert lower case letters to
their upper case equivalents. The conversion affects only the
characters "a" through "z". There are two flavors:
<oldvalue> ← TTYUP(<newvalue>);
This controls conversion of strings returned by all the TTY
input routines in which no breakset is specified. If <newvalue> is
TRUE, conversion will subsequently occur; if FALSE, conversion is
disabled, the previous value is returned, so one may nest cleanly. A
TTYUP call with <newvalue> false will cancel any previous true calls.
<oldvalue> gets set to the value <newvalue> used in the previous call.
A new breakset mode, "K", asks for lower to upper case
conversion. Conversion takes place before the character is checked for
breaking or omission. The breakset mode "F" turns off mode "K", undoing
the conversion. "F" is the default.
SETPL - 7.4
SETPL(channel, @linnum, @pagnum, @sosnum)
This new runtime routine allows one to keep track of the string
input from "channel". Whenever a '12 (linefeed) is encountered,
"linnum" is incremented. Whenever a '14 (form-feed) is encountered,
"pagnum" is incremented, and "linnum" is zeroed. Whenever an SOS line
number is encountered, it is placed into "sosnum". When fully
4
CMU Sail Update March 19, 1974
implemented (soon?), this will work on the INPUT, INTIN, and REALIN
functions as well.
SETSTS/GETSTS - 7.4
Two new runtime routines have been added:
SETSTS(<channel>,<status>);
This issues a SETSTS UUO of the given <status> on <channel>.
<status> ← GETSTS(<channel>);
This returns the results of the GETSTS UUO on <channel>.
INOUT - 7.4
INOUT(<inchan>,<outchan>,<howmany>);
INOUT reads from <inchan> and writes onto <outchan>. <howmany>
words are transferred. Each channel must be open in a mode between '10
and '15. On return, the appropriate EOF variables for the two channels
are set as if ARRYOUTS and ARRYINS had occurred. If <howmany> is
negative, transferring will cease only on EOF or a device error.
INOUT simulates multiple ARRAYIN-ARRYOUT combinations. It BLTS
the data from one set of buffers to the other, making each BLT as large
as possible, consistent with a) the number of words asked to be
transferred and b) the number of words available in the input and output
buffers.
NEW MTAPE OPTIONS - 7.4
In export SAIL, MTAPE(chnl,"I") sets the 'IBM compatible' mode
for a tape drive. (It does an MTAPE chnl,101.)
MTAPE(chnl,NULL) issues the MTAPE 0 command, which causes a wait
until all activity on the magtape ceases.
INCHWL - 7.5
The activation character in INCHWL is not included in the
string, but is put into !SKIP!. CRLF puts a <CR> into !SKIP! and throws
away the <LF>.
At CMU INCHWL breaks only on linefeeds and carriage returns.
only
5
CMU Sail Update March 19, 1974
EXECUTION TIME ROUTINES - 8
CVOS - 8.1
CVOS will do no type coercion on real arguments; it puts out the
octal equivalent of the hardware floating-point format.
USERERR - 8.3
An optional parameter has been added to USERERR, in the form:
USERERR(value,code,"msg","response")
The string "response", if included in the USERERR call, will be
scanned before the input buffer is scanned. In fact, if the string
"response" satisfies the error handler, the input buffer will not be
scanned at all. An example:
USERERR(0,1,NULL,"QLA");
This resets the mode of the error handler to Quiet, Logging, and
Automatic continuation, then continues.
In regard to USERERR in general, the error message generated has
a format described in 20.1.
ARRCLR - 8.5
This new runtime routine clears any kind of array. That is,
arthmetic arrays get filled with zeros, string arrays with NULLs, and
itemvar arrays with ANYs. One may use ARRCLR with set and list arrays,
but the set and list space will be lost (i.e. un-garbage-collectable).
The syntax is:
ARRCLR (arry)
ARRCLR (arry,val)
In the second case, "val" is either an integer or a real number,
and "arry" will be filled with it. This will not work on string or list
arrays, and real for "val" won't work for itemvar arrays. If needed,
CVI will be applied to "val".
6
CMU Sail Update March 19, 1974
FILEINFO - 8.5
FILEINFO documentation is wrong. What you usually get is:
Filename
Ext.,Date
Prot(9)Mode(4)Time(11)Date(12)
Negative swapped word count (if you did a LOOKUP)
0 (unless you opened device in magic mode)
0
What you get is the six words from the last LOOKUP or ENTER.
For details see the monitor manual.
NUMERICAL ROUTINES - 8a
THE ROUTINES - 8a.1
A collection of numerical routines has been added to SAIL.
These are pre-declared in the compiler, and are loaded from the standard
SAIL library. The functions are quite standard; following are the
equivalent definitions:
1. The standard trigonometric functions. ASIN, ACOS, ATAN and ATAN2
return results in radians. The ATAN2 call takes arc-tangent of the
quotient of its arguments; in this way, it correctly preserves sign
information.
REAL PROCEDURE SIN (REAL radians);
REAL PROCEDURE COS (REAL radians);
REAL PROCEDURE SIND (REAL degrees);
REAL PROCEDURE COSD (REAL degrees);
REAL PROCEDURE ASIN (REAL argument);
REAL PROCEDURE ACOS (REAL argument);
REAL PROCEDURE ATAN (REAL argument);
REAL PROCEDURE ATAN2 (REAL numerator,denominator);
2. The hyperbolic trigonometric functions.
REAL PROCEDURE SINH (REAL argument);
REAL PROCEDURE COSH (REAL argument);
REAL PROCEDURE TANH (REAL argument);
7
CMU Sail Update March 19, 1974
3. The square-root function:
REAL PROCEDURE SQRT (REAL argument);
4. A pseudo-random number generator. The argument specifies a new
value for the seed (If the argument is 0, the old seed value is
used. Thus to get differing random numbers, this argument should be
zero.) Results are normalized to lie in the range [0,1].
REAL PROCEDURE RAN (INTEGER seed);
5. Logarithm and exponentiation functions. These functions are the
same ones used by the SAIL exponentiation operator. The base is e
(2.71828182845904). The logarithm to the base 10 of e is
.4342944819.
REAL PROCEDURE LOG (REAL argument);
REAL PROCEDURE EXP (REAL argument);
These functions may occasionally be asked to compute numbers
that lie outside the range of legal floating-point numbers on the PDP-
10. In these cases, the routines issue sprightly error messages that
are continuable.
OVERFLOW/UNDERFLOW - 8a.2
In order to better perform their tasks, these routines enable
the system interrupt facility for floating-point overflow and underflow
errors. If an underflow is detected, the results are set to 0 (a feat
not done by the PDP-10 hardware, alas). Be aware that such underflow
fixups will be done to every underflow that occurs in your program.
If you would like to be informed of any numerical exceptions,
you can call the runtime:
TRIGINI (LOCATION(simple-procedure-name));
Every floating-point exception that is not expected by the
interrupt handler (the numerical routines use a special convention to
indicate that arithmetic exception was expected) will cause the
specified simple procedure to be called. This procedure may look around
the world as described in the Manual for 'export' interrupt handlers,
section 16.2. If no TRIGINI call is done, the interrupt routine will
simply dismiss unexpected floating-point interrupts.
8
CMU Sail Update March 19, 1974
ENTRY POINTS - 8a.3
In order to avoid confusion (by the loader) with older trig
packages, the entry points of the SAIL arithmetic routines all have a
"$" appended to the end. Thus, SIN has the entry point SIN$, etc.
WARNING: If a program plans to use the SAIL intrinsic numerical
routines, it should NOT include external declarations to them, since
this will probably cause the FORTRAN library routines to be loaded.
MACROS AND CONDITIONAL COMPILATION - 9
DEFINE - 9.3
DEFINE now observes block structure, statements in the preface
to the contrary. DEFINEing a macro name that has already been DEFINEd
at an outer level will suspend the outer definition until the inner
block is exited. If a macro name is DEFINEd twice at the same level, an
error of "duplicate identifier declaration" wil be issued.
REDEFINE - 9.3
REDEFINE has been added to allow redefinitions of a macros name
at the same level. If the name was not previously defined, the effect
of REDEFINE is the same as DEFINE. In the CMU manual, under SCOPE, some
DEFINEs should really be REDEFINES. In the example, the most deeply
nested DEFINE should also be a REDEFINE. If left as a DEFINE, the
output is "LOSSAGE IN OUTER BLOCK".
DEFINE/REDEFINE - 9.3
A left arrow following a macro name when it is declared or
redeclared is legal, and has the same effect as "=".
EVALDEFINE - 9.3
EVALDEFINE may be used in place of DEFINE if one would like the
identifier that follows to be expanded. When one follows a DEFINE with
a macro name, the macro is not expanded, but rather the macro name is
declared at the current lexical level and assigned the specified macro
body. EVALDEFINE gets you around that. It is helpful in the automatic
generation of macro names.
9
CMU Sail Update March 19, 1974
EVALREDEFINE - 9.3
EVALREDEFINE bears the same relationship to REDEFINE as
EVALDEFINE does to DEFINE.
NOMAC - 9.3
NOMAC appearing before an identifier almost anyplace keeps that
identifier from being expanded, should it turn out to be a macro E.G.:
begin define a=3;
begin integer nomac a;
a←5;
end;
end;
ASSIGNC - 9.3
The following compile time construct makes recursive macros
easier:
ASSIGNC <name> = <macro_body>;
<name> must be a formal to a macro, and <macro_body> may be any
macro body. Thereafter, whenever <name> is instantiated, the body
corresponding to <macro_body> is used in the expansion rather than the
text passed to the formal at the macro call.
RESTRICTION: ASSIGNC may only appear in the body of the macro
that <name> is a formal of. If it appears anywhere else, the <name>
will be expanded like any good formal, and that text used in the ASSIGNC
as <name>. Unless you're being very clever, this is probably not what
you want.
CVPS - 9.4
CVPS(<macro_parameter>) converts <macro_parameter> to a string
and returns the string. See about macro parameters in section 9.4 of
the manual.
IFC/IFCR - 9.5
IFC has been changed so that macros are expanded in the false
part. They were previously not expanded. (e.g. this allows CMUs old
BIGCOMMENT! and STOPCOMMENT!, which have now been defined in BAYSAI).
10
CMU Sail Update March 19, 1974
IFCR has been added to replace the old IFC. It is exactly the
same as IFC was.
LEAP STATEMENTS - 11
BRACKETED TRIPLES - 11.4
If a designated Bracketed Triple is not found, then BINDIT is
returned and no error message is given.
PROCESSES - 13
SPROUT APPLY - 13.3
The <procedure call> in a SPROUT statement may be an APPLY
construct. In this case SPROUT will do the "right" thing about setting
up the static link for the APPLY. That is, "up-level" references by the
process will be made to the same variable instances that would be used
if the APPLY did not occur in a SPROUT statement.
However, there is a glitch. The sprout mechanism is not yet
smart enough to find out the block of the declaration of the procedure
used to define the procedure item. It would be nice if it did, since
then it could warn the user when that block was exited and yet the
process was still alive, and thus potentially able to refer to
deallocated arrays and etc. What the sprout does instead is assume the
procedure was declared in the outer block. This may be fixed
eventually, but in the meantime some extra care should be taken when
using apply in sprouts to avoid exiting a block with dependents.
Similarly, be warned that the "DEPENDENTS(<blockid>)" construct may not
give the right result for sprout applies. Section 13.3 of the manual
contains the description of this protection mechanism for non-APPLY
sprouts.
SPROUT_DEFAULTS - 13.3
SAIL now provides a mechanism by which the user may specify
the "default" options to be used when individual procedures are
sprouted.
11
CMU Sail Update March 19, 1974
Syntax:
PROCEDURE <procid> ...
BEGIN
<some declarations>;
SPROUT_DEFAULTS <integer constant>;
<perhaps some more declarations>;
:
:
<statements>
:
END;
In other words, SPROUT_DEFAULTS is a declaration.
Semantics:
If one of the "allocation" fields of the options word passed to
the SPROUT routine -- i.e. QUANTUM, STRINGSTACK, PSTACK, or PRIORITY --
is zero, then SPROUT will look at the corresponding field of the
specified <integer constant> for the procedure being sprouted. If the
field is non-zero, then that value will be used; otherwise the current
"system" default will be used.
NOTE: SPROUT_DEFAULTS only applies to "allocations", i.e. the
process status control bits (e.g. SUSPME) are not affected.
Example:
RECURSIVE PROCEDURE FOO;
BEGIN
SPROUT_DEFAULTS STRINGSTACK(10);
INTEGER XXX;
:
:
END;
:
SPROUT(P1,FOO,STRINGSTACK(3));
SPROUT(P2,FOO);
COMMENT P1 will have a string stack of 3*32 words.
P2 will have a string stack of 10*32 words;
SUSPEND - 13.3
SUSPEND now behaves like RESUME in that it returns an item.
itm ← SUSPEND(<process item>)
12
CMU Sail Update March 19, 1974
Frequently, one is suspending some other process than the one
that is executing the SUSPEND statement. In this case, the item
returned is ANY. However, in cases like:
X ← SUSPEND(myproc);
where the process suspends itself, it might happen that this
process is made running by a RESUME from another process. If so, then X
receives the <return_item> that was an argument to the RESUME.
FAIL AND SUCCEED - 13.3
FAIL and SUCCEED now behave like RESUME and SUSPEND in that they
also return an item. The item returned is ANY unless the Matching
Procedure containing the FAIL or SUCCEED was (1) sprouted as a process,
and (2) made running by a RESUME construct. In the latter case, the
item returned is the <return_item> that was an argument to the RESUME.
[Note that the only case in which a Matching Procedure can be
reactivated at a FAIL is by being RESUMEd.]
PROCEDURE VARIABLES - 15
ARG_LIST - 15.2
A list construct has been added:
ARG_LIST(<arg1>,...,<argn>)
This assembles a list of temporary reference items that will be
deleted by APPLY after the applied procedure returns. Except for being
temporary, the reference items created are just like those created by
REF_ITEM.
13
CMU Sail Update March 19, 1974
USING SAIL - 19
SWITCH F - 19.3
20F surrounds macro expansions with "<>", not "⊂⊃".
CONDITIONAL COMPILATION - 19.3
Conditional compilation is now compatible with listing files.
The conditional compilation reserved words don't get listed, and the
condition doesn't get listed. All that does get listed is the actual
code that will be executed.
DEBUGGING SAIL PROGRAMS - 20
ERROR MODES - 20.1
The error message procedure can be modified by setting various
modes. One sets a mode by including the appropriate letter before the
response. Any of the four modes may be reset by including a minus sign
("-") before them, e.g. "-Q". Error modes can also be set with the
construct REQUIRE <string-const> ERROR!MODES. When the compiler sees
this in any of the source files one is compiling, it reads through the
string constant and sets the modes as it sees their letters. These
modes remain in effect until the end of the compilation or until reset
with a response to an error message, or another REQUIRE ERROR!MODES.
K KEEP type-ahead. Normally, the error handler will flush the
input buffer before looking for response characters. This
mode allows one to type ahead. As of this date, KEEP has not
been implemented, so it works only for a <lf>.
Q QUIET. If the error is continuable, none of the error
messages will be typed. You will, however, always be notified
of a non-continuable error.
L LOGGING. The first and second items of the error message will
be sent to a file named <program>.LOG where <program> is the
name of the file of the main program. If you would rather
have another name, use F<file specification>, which must be a
legal file name and PPN. The default extension is LOG and the
default PPN is that of the job. The .LOG file (or whatever
14
CMU Sail Update March 19, 1974
it's called) is closed when one's program finishes
compilation, or the compilation is terminated with the S, X, E
or T responses.
N NUMBERS. This mode causes the message "CALLED FROM xxx LAST
SAIL CALL AT yyyy" to be typed before the question mark or
arrow. Useful to compiler debuggers and hand coders.
Note that setting a mode does nothing but set a mode; it does
not cause continuation.
Note also that the last three modes are implemented only in the
compiler. One can get the effect of error modes at runtime by using the
USER ERROR procedures.
USER ERROR PROCEDURES - 20.2
A user error procedure is a user procedure that is run before or
instead of the SAIL error handler everytime an error occurs at runtime.
This includes all array errors, IO errors, Leapish errors and all
USERERRs. It does not include system errors, such as Ill Mem Ref or Ill
UUO.
The procedure one uses for a user error procedure must be of the
following type:
SIMPLE INTEGER PROCEDURE proc (INTEGER loc; STRING msg, rsp);
Only the names proc, loc, msg, and rsp may vary from the example
above, except that one may declare the procedure INTERNAL if one wishes
to use it across files.
Whenever the external integer !ERRP! is loaded with
LOCATION(proc), the error handler will call proc before it does anything
else. It will set loc to the core location of the call to the error
handler. Msg will be the message that it would have printed. Rsp will
be non-NULL only if the error was from a USERERR which had response
string argument. Proc can do anything that a simple procedure can do.
When it exits, it should return an integer which tells the error
handler if it should do anything more. If the integer is 0, the error
handler will (1) print the message, (2) print the location, and (3)
query the tty and dispatch on the response character (i.e ask for a
<cr>, <lf>, etc.). If the right half of the integer is non-zero, it is
taken as the ascii for a character to dispatch upon. The left half may
have two bits to control printing. If bit 17 in the integer is on,
message printing is inhibited. If bit 16 is on, then the location
printing is inhibited. For example, "X"+(1 LSH 18) will cause the
15
CMU Sail Update March 19, 1974
location to be printed and the program exited. "C"+(3 LSH 18) will cause
the error handler to continue without printing anything.
Note that simple procedures can not do a non-local GOTO.
However, the effect of a non-local GOTO can be achieved in a user error
procedure by loading the external integer !ERRJ! with the LOCATION of a
label. The label should be on a call to a non-simple procedure which
does the desired GOTO. The error handler clears !ERRJ! before calling
the procedure in !ERRP!. If !ERRJ! is non-zero when the user procedure
returns, and continuing was specified, then the error handler's exit
consists of a simple transfer to that location.
WARNING! Handling errors from strange places like the string
garbage collector and the core management routines will get you into
deep trouble.
APPENDICES
APPENDIX 4
The synonym for "such that" is "|" ("?:") not "↓".
APPENDIX 11
The "33 through 36" should be "33 through 35".
APPENDIX 15
Under BYTP change "count" to "length".
16