Post by Don BaccusPost by Johnny BillquistAnyway, I just went through the release notes for PDP-11 PASCAL/RSX-11
(V1.3, which was the last release) right now, just to remind myself how
different it was/is. I can share that file, if you are interested.
I would love to see that. To be honest, I don't think I ever bothered to read it.
Trying to attach it to this post.
Post by Don BaccusPost by Johnny BillquistBut it's really very VAX PASCAL compatible, with a completely different
syntax than OMSI Pascal for lots of rather core things.
That is something I do remember, that they wanted compatibility with VAX Pascal. That made sense from their POV to make it simple to write programs to work with both.
Definitely makes sense, yes. The ability to move the code from one
machine to another, recompile, and off you go certainly is an advantage.
Post by Don BaccusOf course, same was true with our Pascal-2 on the PDP-11, VAX, MC68000, NS32000, MIPS, Sparc, x86 as time went by. We looked at compatibility differently than DEC did, spanning manufacturers and operating systems. DEC's insistence on trying to shoehorn everything into their worldview of a DEC ecosystem was a major reason for their collapse IMO.
There were many reasons why DEC collapsed. I'm sure this was one.
Post by Don BaccusPost by Johnny BillquistI'm amazed that
it's the same codebase. Not to mention that it's pretty bad.
I think they just modified the front end. So did we as we went on to support Modula-2, C, and C++.
Possible. I guess I would need to see more of the internals to tell. The
feeling of PDP-11 Pascal, and OMSI Pascal-2 is definitely very different
at least.
Post by Don BaccusThe compiler technology was designed to support multiple languages and multiple targets, with an optimizer that worked on an abstract model of the program that applied to a wide variety of machine architectures.
This is common now (i.e. the GNU suite of compilers and others) but wasn't when I started designing the system in 1976, especially in the realm of commercial language processing products.
Post by Johnny Billquisteven install it usually. Just have OMSI Pascal installed, which is way
better (even if it is the same codebase :-D ).
It pleases me to hear this :) Thank you.
I'm happy you made the product. I've even had to support a customer who
made extensive use of Pascal-2 under RSX, and it was working fine. They
might still be running the stuff, but it might also be that it's being
decommissioned as we speak. The main responsible person retired last
year... That is commonly a time when people start changing things around.
Johnny
(And I need to paste the release notes below, stupid software nowadays
thinks something like this is a dangerous binary attachment if I try to
attach it... Sigh...)
=========snip=========
Introduction
This document contains descriptions of all the corrections to PDP-11
Pascal Version 1.3 since the release of Version 1.2. You'll find that
most of the corrections will be fixes to previous restrictions. At
the end of the document under the heading of restrictions you may find
new restrictions.
PDP-11 PASCAL Version 1.3 Release Notes
Installation Differences between PDP-11 PASCAL Version 1.2 and Version
1.3
An entire new installation procedure has been adopted for this release
of PDP-11 Pascal. This procedure will greatly simplify the
installation process. See Installation Guide for details.
Disk Data Caching and PDP-11 Pascal.
Disk data caching is a feature on RSX-11M-PLUS and Micro/RSX Version
3.0. This feature enhances I/O operations by reducing the number of
physical I/O requests directed to a disk. (See chapter 19 of the
System Manager's Guide for more information.) Because the performance
of PDP-11 Pascal is directly related to the performance of the device
on which it is running, typically the system disk. Enabling disk data
caching can dramatically increase the speed of the compiler.
NOTE
Disk data caching is a SYSGEN option on RSX-11M-PLUS;
while on Micro/RSX you must enable the option in the
SYSPARAM.DAT file and reboot the system. If you're
not sure whether this option exists on your system you
should see the system manager.
To enable disk data caching the following DCL command should be
issued:
$ SET DEVICE Dnx:/CACHE:(CREATE,OVERLAY:8)
Where Dnx: is the device on which the compiler task is located. On
RSX-11M-PLUS systems see your system manager and on Micro/RSX systems
the task is located on DU0:
Tests indicate that when disk data caching is enabled with the above
command line, compiler performance has in most cases doubled.
1
Compiler and OTS Corrections for Version 1.3
This section lists the corrections to the PDP-11 PASCAL compiler and
OTS for Version 1.3.
1. Within certain restrictions, routines can now be declared both
EXTERNAL and GLOBAL within the same compilation unit. The EXTERNAL
declaration must appear first with a complete parameter list and
function result type, if applicable. The parameter list or
function result type do not have to appear on the subsequent GLOBAL
declaration. If the parameter list or result type are included on
the GLOBAL declaration, they are ignored.
This feature applies only to procedures and functions. It allows
all common EXTERNAL routine declarations to be placed in a single
%INCLUDE file for use by several modules.
2. The superset operator now works properly. In previous releases
the results were unpredictable so the subset operator had to be
used in place of the superset operator with the operands reversed.
This is no longer the case.
3. The predeclared function ORD now works correctly when its argument
is the result of a relational operation. For example:
a := a + ORD ( a > b );
4. Using pointers with a file no longer generates bad code when the
file is tested for end of file. For example:
PROGRAM t (OUTPUT, f);
TYPE
file__of__text : TEXT;
VAR
f : _^file__of__text;
BEGIN
NEW (f);
RESET (f_^);
WHILE NOT EOF (f_^) DO
BEGIN
WRITELN (f_^);
READLN (f_^);
END;
END.
5. The compiler now performs the correct initialization when array
constructors are used to initialize multidimensional arrays with
base type, CHAR. For example:
VAR
2
arr : PACKED ARRAY [1..4,1..3] OF CHAR
:= ('abc','def','ghi','jkl');
6. For loop control variables at the program level may be updated
only in a temporary stack location. Attempts to access the value
of the variable used to control the for loop within routines called
directly or indirectly from within the for loop cause a reference
to memory which has not been updated, thus giving incorrect
results.
The recommended wokaround for this problem is to declare the for
loop variable as having the AUTOMATIC attribute. With the
AUTOMATIC attribute no static storage is allocated to the variable
and the variable will be bound to a register thus rendering its
value accesible from anywhere within the program.
As an example
var
i : [automatic] integer;
begin { main program }
.
.
.
for i := 1 to finalvalueofforloop do
begin
.
.
.
end;
.
.
.
end. { main program }
7. The calling mechanism for SEQ11 routines has changed. In Chapter
3 of the PDP-11 Pascal User's Guide and in Chapter 6 of the
Language Reference Manual, reference is made to the calling
mechanism invoked when the SEQ11 directive is used. In the past
all parameters passed to a system directive were forced to be by
reference, i.e. equivalent to a VAR parameter. This meant that it
was not possible to pass a null argument to a system directive.
Now no parameter will be forced to be by reference, the calling
mechanism typically required by SEQ11 calls. The programmer will
be required to pass parameters as explicitly VAR if the calling
mechanism is by reference.
Formerly, the AST mechanism could not be turned off without
altering variables at TKB time. With the above change this has
been corrected. You can, if you wish, declare a SEQ11 routine with
value parameters. You use a value parameter when specifying a null
3
parameter for an AST routine. The use of AST routines is not
supported under Pascal. The following example program shows the
use of the directives SPAWN and WAITFR.
PROGRAM SPAWN(OUTPUT);
{
To compile and build this program use the following MCR
commands:
mcr pas spawn=spawn
mcr tkb spawn/cp=spawn,lb:[1,1]r50lib/lb,pasots/lb
}
TYPE
$BYTE = -128..127;
$STR2 = PACKED ARRAY [1..2] OF CHAR;
$STR6 = PACKED ARRAY [1..6] OF CHAR;
$STR79 = PACKED ARRAY [1..13] OF CHAR;
$INT4 = ARRAY [1..4] OF INTEGER;
$INT5 = ARRAY [1..5] OF INTEGER;
$INT6 = ARRAY [1..6] OF INTEGER;
$INT8 = ARRAY [1..8] OF INTEGER;
$INT13 = ARRAY [1..13] OF INTEGER;
$INT15 = ARRAY [1..15] OF INTEGER;
VAR
Efnbr : $BYTE;
Task : REAL;
Group : $Byte;
Member : $Byte;
Buffer : $INT8;
Command : $str79;
Length : INTEGER;
Lunit : INTEGER;
Device : INTEGER;
Edstat : INTEGER;
Ast : INTEGER;
Astprm : INTEGER;
[EXTERNAL] FUNCTION Rad50 (Nam : $STR6) : REAL; EXTERNAL;
[EXTERNAL] PROCEDURE WAITFR (VAR Efn : $BYTE); seq11;
[EXTERNAL] PROCEDURE Spawn (VAR Tsk : REAL;
VAR Grp : $BYTE;
VAR Mbr : $BYTE;
VAR Efn : $BYTE;
Ast : INTEGER;
VAR Buf : $INT8;
4
VAR Prm : INTEGER;
VAR Com : $STR79;
VAR Len : INTEGER;
VAR Lun : INTEGER;
VAR Dev : INTEGER;
VAR Eds : INTEGER); SEQ11;
BEGIN
Task := RAD50('...DCL');
Group := 0;
Member := 0;
Efnbr := 1;
ast := -1; { Note the use of -1 to indicate to the system
that this is a null parameter. }
Buffer := $int8(0,0,0,0,0,0,0,0);
astprm := 0;
Command := 'DIR SPAWN.PAS'
Length := 13;
Lunit := 0;
Device := 0;
Edstat := 0;
spawn ( Task,Group,Member,Efnbr,ast,Buffer,astprm,
Command,Length,Lunit,Device,Edstat);
waitfr ( efnbr );
END.
8. The set intersection operator no longer causes programs to exit
with Memory Protect Violation due to the modification of a read
only PSECT. The conditions which triggered the Memory Protect
Violation were:
1. the second operand of the set intersection was a constant set
2. the program was task built with the /MU switch.
5
The following program illustrates the construct which gave rise to
the problem.
program setIntersection;
type
carType = (pinto, chevy, duster, fiero, escort);
setOfCarType = set of carType;
const
ford = [pinto, escort];
var
mycars : setOfCarType := [fiero, escort];
begin { setIntersection }
if (mycars * ford) = [escort]
then
.
.
end. { setIntersection }
9. Elements of a PACKED array having the EXTERNAL attribute are now
correctly referenced if at least two variables had to be accessed
to generate the index into to the array.
A program which exemplifies the context of the problem follows.
program externalPackedArray;
type
flagarr = packed array [1..6] of boolean;
boxd = packed record
flag : flagarr;
end;
boxdat = array [1..5] of boxd;
var
A : [external] boxdat;
box : integer := 1;
part : integer := 1;
temp : boolean;
begin { externalPackedArray }
temp := A[box].flag[part];
if temp
6
then
...
else
...
end. { externalPackedArray }
10. Added support for logical names on RSX-11M-Plus Version 3.0.
This includes logical names on the Pascal command line and within
programs, e.g. the file name specification in an OPEN statement
can now be a logical name.
11. The optimizer has been fixed to no loinger eliminate code that it
should not.
In the following program the statement "exter1 [i] := exter2 [i]"
was being optimized out by the code generator. This unwanted
optimization was done only if two variables were of the same user
defined type and were declared as GLOBAL variables in the same
module.
MODULE testglobal;
VAR
exter1 : [ GLOBAL ] ARRAY [1..10] OF CHAR;
exter2 : [ GLOBAL ] ARRAY [1..10] OF CHAR;
[ GLOBAL ] PROCEDURE assign;
VAR
i : integer;
BEGIN
FOR i := 1 to 5 DO
exter1 [i] := exter2 [i];
END;
END.
Also, in previous versions TST instructions were sometimes
eliminated from the generated code on the assumption that the
condition codes had already been set.
These no longer happen.
12. Programs compiled with the /CD:EIS switch can now be built in I-
and D-space.
7
13. Integer subranges requiring less than a word of storage are now
correctly read into packed structures.
14. A syntactically incorrect CASE statement containing an otherwise
clause and missing its END token, nested within a CASE statement
and preceding the otherwise clause of the outer CASE statement, no
longer causes the compiler to loop infinitely.
15. The floating point version of the round function no longer
destroys the value of common sub-expressions. For example, with
the following declarations
var
i : integer;
x, y : real;
the following code caused x/2.0, a common sub-expression, to be
destroyed during the in line floating point computation of the
round function
...
i := round(x/2.0);
y := x/ 2.0;
...
16. Arguments passed to the option routine IDATE are now correctly
popped of the stack before control returns to the calling routine.
17. A problem was encountered when comparing character expressions
involving a value within the multinational character set exceeding
ordinal value 127. This includes the checking of subranges of type
CHAR at runtime (invoking the /CK switch at compile time). Such
expressions (including arrays of CHAR) are now compared correctly,
with the exceptions which follow.
1. comparison of character constants;
2. comparison of the results of the predeclared CHR function
having constant arguments;
8
3. comparison of the results of user defined functions returning
values of type CHAR.
Comparison of the ordinal values of the above exceptions yield
correct results.
Character values confined to the ASCII collating sequence are
compared correctly.
18. Attempting to initialise a structure using a constructor which
itself contains a structured constant no longer causes the compiler
to enter an infinite loop.
For example
Program StructuredConstructor;
{ Pascal proceeds into an apparently infinite loop on this
program.
}
TYPE
array_2 = array[1..2] of integer;
array_12 = array[1..2] of array_2;
CONST
eights = array_2 (8,8);
VAR
all_eights : array_12 := (eights, eights);
BEGIN
END.
19. If a compile time expression contains an integer division by zero
an error message is now issued by the compiler. Formerly, a run
time error was detected by the operating system and the compiler
task was terminated.
20. External write access is now properly denied when the share
parameter of an OPEN statement is set to READONLY or NONE.
However, read access can never be denied under any circumstances
due to a constraint of FCS.
21. Formerly, expressions within procedures or functions, involving
predeclared boolean functions and boolean constants caused Pascal
to terminate processing. The compiler would exit with a "COMPILER
LIMIT EXCEEDED" message. This condition is now handled properly.
An example of the code which would have caused the problem follows.
9
PROCEDURE boolean_comparison_error;
BEGIN
.
.
IF odd(i) AND boolean_const = boolean_const
then
.
.
END;
22. Pascal no longer generates incorrect (unsigned) range checking
instructions on the assignment of the ORD of a character expression
to an integer subrange.
A program which exposes the condition follows:
PROGRAM charord (output);
TYPE
threeValue = -1..1;
VAR
i : threeValue;
c : char;
BEGIN { charord }
c := chr(0);
i := ord(c)
END. { charord }
23. PDP-11 Pascal now accepts an [EXTERNAL] function as an actual
function parameter.
24. The predeclared procedure TIME now returns the system time with
an accuracy of hundredths of seconds. Formerly the time returned
in the array parameter to the TIME procedure was accurate only to
seconds. PDP-11 Pascal behaviour is now consistent with the
documented behaviour of the predeclared procedure TIME.
25. There is no longer a definition of the symbol "OUTPUT::" in the
macro listing file (if one is requested at compile time) when the
definition should not exist. This condition used to arrise when
OUTPUT was not explicitly declared in an [OVERLAID]MODULE. The
object code, however, has always been correct with respect to this
problem.
10
26. FOR loops now work properly. The problem was that R5 is a
reserved register for routines that make non-local variable
references. However, it was sometimes allocated as the FOR loop
control variable. When the procedure call was inside the loop, the
contents of R5 was being corrupted. The following code section
demonstrates this phenomenon
PROGRAM UK007 (INPUT, OUTPUT);
PROCEDURE DUM_CAST;
BEGIN
WRITELN('Dumbstruck!');
END;
PROCEDURE BUM_CODE ( PROCEDURE subroutine );
VAR
I : INTEGER;
BEGIN
FOR I := 1 TO 3 DO subroutine ;
END;
BEGIN
BUM_CODE( DUM_CAST );
END.
27. Boolean operations on packed arrays now work properly.
Previously, a Compiler Limit Error was generated in some cases
where AND, and OR were operating on packed arrays with Common
Sub-Expressions across an assignment statement. An example of this
type of code follows:
Program bomb;
TYPE
bin_form=packed array [1 .. 16] of boolean;
VAR
count :integer := 1;
bin_num1, bin_num2 :[external]bin_form;
tem_num1, tem_num2 :bin_form;
BEGIN
tem_num1[count] := bin_num1[count] or bin_num2[count];
{ the next line causes the error }
tem_num2[count] := bin_num1[count] and bin_num2[count];
END.
This was a result of too many internal keys being generated and not
freed when their purpose was served. This problem has been
corrected so that excess keys are not wasted.
28. NOT now properly determines the length of its operand when that
operand is part of a CSE whose destination is packed.
11
Occasionally, the NOT operator would incorrectly determine the
length of its operand when that operand had been a part of a Common
Sub-Expression whose end result was packed. The code that follows
is an example of this.
Program NEGB;
VAR
x :integer;
dummy : BOOLEAN; { force i to be allocated on an odd address }
i :boolean;
a :PACKED ARRAY [1..9,1..9] OF BOOLEAN;
BEGIN
i := false;
For x := 1 to 9 DO
BEGIN
a[x,x] := i; { force the common sub expression }
i := NOT i; { problem occurs here }
END;
END.
In this example, the assignment, "i := NOT i" was mishandled by
generating a NEG P$LOCL+3 instead of a NEGB P$LOCL+3. This mistake
has been corrected.
29. Multiple concurrent compilations in the same UFD are now
possible. The user is no longer restricted to one compilation at a
time in a single UFD. This problem has been corrected through the
renaming of the compiler's internal temporary workfiles. This
correction will be transparent to the user as long as compilation
terminates normally. If compilation is aborted, however, three of
the internal files which will no longer liter your directories are
TEMP1.TMP, TEMP2.TMP, and LIST.TMP. Instead, the files
<sourcefilename>.TM1, <sourcefilename>.TM2, and
<sourcefilename>.TML will be there.
The users is still restricted from compiling multiple versions of
the same file in the same UFD at the same time.
30. In previous updates to PDP-11 Pascal it was not possible to
update the OTS modules when the update kit was not on the same
device as the directory containing the UFD [11,36]. This has been
corrected.
31. A constant in an ARRAY index expression formerly caused
subsequent constants in that expression to be ignored. For example
the program fragment which follows
CONST
c = 2;
.
.
12
.
for k := 1 to 3 do
arrayof10[ k + 3 + c ] := arrayof3[ k ];
resulted in k + 3 + c evaluating to 4, 5 and 6 rather than 6, 7,
and 8.
This no longer happens.
Documentation Changes
1. The PDP-11 PASCAL cover letter, under the section titled "Media"
lists the different types of media incompletely. The complete list
of distribution media available by operating system should read:
RSX-11M and RSX-11M-PLUS
o One 9-track 1600 BPI magnetic tape
o One 9-track 800 BPI magnetic tape
o One TK50 tape cartridge
o One RL02 disk cartridge
o One RK07 disk cartridge
Micro/RSX
o Two RX50 diskettes
o One TK50 tape cartridge
2. Appendix E of the PDP-11 PASCAL Language Reference Manual
describes the differences between PDP-11 PASCAL and VAX-11 PASCAL.
This section should include a discussion of differences in labels
for CASE statements. In VAX PASCAL, labels for CASE statements
with an index variable of type INTEGER must have a range smaller
than 1000 elements. PDP-11 PASCAL allows an index variable of
INTEGER to have labels with a range of 2001 elements.
3. Section E.4.2.1 of the PDP-11 PASCAL/RSX-11 User's Guide contains
a macro for calling SETIO. This macro has changed and should now
read as follows:
.MACRO SETIO ARGS
.PSECT $$OTSD,D,RO,LCL,CON
SETDAT=.
.WORD 6+<2*ARGS>
.PSECT $$OTSI,I,RO,LCL,CON
13
MOV #SETDAT,-(SP)
JSR R5,$$SETIO
.ENDM SETIO
4. Section E.5.5 of the PDP-11 PASCAL/RSX-11 User's Guide describes
the sequence of instructions when the UPDATE routine ($PUPDT) is
called. This sequence is incorrect and should read as follows:
o Obtains the file-variable pointer from offset V$FILE.
o Obtains the current record number from F.RCNM and F.RCNM+2 in
FDB.
o Calls the FCS-11 macro PUT$ to write the record.
o Calls the FCS-11 macro GET$ to fill the buffer with the next
record.
5. The default device for the standard Input and Output files cannot
be overridden as is implied in Section 2.1 of the PDP-11
PASCAL/RSX-11 User's Guide. The device for these standard files is
always TI:.
6. Table A-1 in Section A.1.4 of the PDP-11 PASCAL/RSX-11 User's
Guide defines the limit for nesting procedures at 40. Given the
current default values provided for building the PDP-11 PASCAL
compiler, the actual limit for nesting procedures is 19. When this
limit is reached, a stack overflow error usually occurs.
Increasing the stack size and rebuilding the compiler increases the
procedure-nesting limit, but if the stack is too large, a dynamic
storage allocation error can occur.
7. Section 5.4.3 of the PDP-11 PASCAL/RSX-11 User's Guide implies
that the file PASOTS.ODL should be used exactly as it is written.
In fact, the file is provided as an example of the OTS routines
that can be overlaid. The routines you indicate as overlaid in
PASOTS.ODL depend on the application involved. For example, if
space is a consideration, you may overlay .PARSE, .CSI1, and .CSI2;
however, if your application includes modules written in MACRO that
reference FCS routines, overlaying .PARSE, .CSI1, and .CSI2 may
cause conflicting entry points.
The intention was to provide PASOTS.ODL as a starting point for
tailoring an overlaid OTS to your specific application. You may
also find that not using the co-tree structure given in Section
5.4.3 of the PDP-11 PASCAL/RSX-11 User's Guide and incorporating
the OTS overlays into the task overlays can reduce task size even
further, depending on the application.
14
8. Appendix A of the PDP-11 PASCAL/RSX-11 User's Guide provides
information on the compile-time error messages issued by the PDP-11
PASCAL compiler. The warning level message given for Error 150
warns that a variable was used before a value was assigned to it.
Uninitialized variables are flagged in this manner because PDP-11
PASCAL does not provide default values, so the run-time behavior of
the program is unpredictable.
There are two cases involving uninitialized GLOBAL and EXTERNAL
variables for which this warning is not given. If a variable is
declared with the EXTERNAL attribute or if the variable is declared
with the GLOBAL attribute and there is at least one procedure or
function in the program that has been declared external. These
cases are not flagged because the variable may have been
initialized in a module other than the one it appears in. All
other instances of uninitialized variables are flagged.
9. Section 1.5 of the PDP-11 PASCAL Language Reference Manual
describes the use of the %INCLUDE directive. The paragraph that
explains 'file-spec' should read as follows:
file-spec
is the file specification of the file to be included. (See
the PDP-11 PASCAL/RSX-11 User's Guide for details on file
specifications.) Note that if you do not specify a file
extension, no default is assumed.
10. The comments in the example in Section 3.2.5 of the PDP-11
PASCAL/RSX-11 User's Guide are incorrect. The example should read
as follows:
MOV #ADR1,-(SP) ; ADDRESS OF THE 1ST ARGUMENT,
; VAR PARAMETER
MOV VAL2,-(SP) ; VALUE OF THE 2ND ARGUMENT,
; VALUE PARAMETER
.
.
.
MOV #ADRN,-(SP) ; ADDRESS OF THE NTH ARGUMENT,
; VAR PARAMETER
JSR PC,SUB ; CALL SUBROUTINE
11. Section 8.3.7 and Section 8.4.1 of the PDP-11 PASCAL Language
Reference Manual discuss the Disposition parameter PRINT_DELETE for
the OPEN and CLOSE procedures respectively. The manual incorrectly
states that this parameter specifies that a file is to be deleted
after it is printed. There is no support for this file operation.
(The PRINT_DELETE parameter is present only to allow compatibility
with VAX PASCAL.) The PRINT_DELETE parameter produces the same
results as the PRINT parameter.
15
12. Section 2.4.3 of the PDP-11 PASCAL/RSX-11 User's Guide mentions
the LOCATE procedure. This procedure is not supported in PDP-11
PASCAL.
13. Section A.2.2 of the PDP-11 PASCAL/RSX-11 User's Guide lists
Object Time System Diagnostic Messages. This section should
include the following error message:
12 RESET is not allowed on an unopened internal file -- Fatal
Explanation: Because an internal file is a scratch file and
has not been opened, it cannot be reset.
14. Section E.5.2.1 of the PDP-11 PASCAL/RSX-11 User's Guide
describes OPEN Procedure Processing. The discussion of the UNKNOWN
value for the history parameter fails to consider if the file
FA.CRE is already present. The text should read as follows:
"UNKNOWN clears FA.CRE if the file is present. Otherwise, it sets
FA.CRE." Table E-4 should also be updated to include this
information.
15. Section E.5.2.2 of the PDP-11 PASCAL/RSX-11 User's Guide lists a
sample PASCAL program and User Open routine. It includes the
following line:
MOV (SP),-(SP)
This line should be deleted from the example. It is now
automatically included in the OTS so that the caller provides the
storage and knows where the answer will go in the stack. If this
line is in your User Action routines, remove it and reassemble the
routines.
16. Section E.9 of the PDP-11 PASCAL/RSX-11 User's Guide lists
routines currently in the OTS resident library supplied by PDP-11
PASCAL. The text should include the procedure $OPDYM which
performs dynamic memory allocation.
17. PDP-11 PASCAL does not support complex compile-time expressions
for constants. Therefore, the text in Section 4.2 of the PDP-11
PASCAL Language Reference Manual should be corrected. The
metalanguage symbol "exp" should be defined as "A simple
compile-time expression." The constant declaration, "Almost_Pi =
22/7;" should be deleted; it does not work.
18. Table 3-6 in Section 3.2.5 of the PDP-11 PASCAL Language
Reference Manual is not complete. It should include the following
additional Set Operators:
= A=B TRUE if set A is equal to set B
<> A<>B TRUE if set A is not equal to set B
16
<= A<=B TRUE if set A is a subset of set B
Post by Don Baccus= A>=B TRUE if set B is a subset of set A
IN C IN B TRUE if set C is an element of set B
19. Section 10.2 of the PDP-11 PASCAL Language Reference Manual makes
the following statement about the allocation attribute STATIC:
"Static variables must have names that are unique within the first
six characters." This restriction on variable names is true only
for variables declared with the visibility attribute GLOBAL
discussed in Section 10.3.
20. The Index for the PDP-11 PASCAL RSX-11 User's Guide lists the
file PASREC.CMD at page 5-12. The file indexed should be
PASRES.CMD.
21. The following should be at the end of Section E.5.2.2 of the UG.
NOTE
In order to assemble a User Action routine you use
the following command line
Post by Don BaccusMAC NOSUP,NOSUP/-SP=OPCOM,FIGFPP,NOSUP
The files OPCOM.MAC and FIGFPP.MAC (or FIGEIS.MAC
if you are using the Extended Instruction Set) are
the OTS parameter files. They can be found in UFD
LB:[1,1] on your system. These files are copied
automatically during the installation of the
compiler.
22. Section D.2 of Appendix D in the PDP-11 Pascal Users Guide
indicates how to return an error status from an user task by using
the $PEXIT routine in conjunction with the external variable $EXST.
The name of the variable is incorrect; it should be called $XST and
declared as:
$XST : [ EXTERNAL ] INTEGER;
23. Section 8.3.8 of the PDP-11 Pascal Language Reference Manual
describes the use of the SHARE parameter of the OPEN statement.
The paragraph that explains 'NONE' should read as follows:
NONE is handled exactly the same way as READONLY. This
condition is due to a constraint of FCS which always permits
concurrent tasks read access to a file.
17
24. Appendix B, section B.5 SIN Real Floating-Point Sine of the
PDP-11 Pascal User's Guide should note that for arguments X >=
32768.0 the PDP-11 Pascal Pre-declared SIN function will return
zero (0).
The section should begin
SIN(X) is computed as: SIN(X) = 0 if X >= 32768.0
otherwise . . .
Section 7.1.2 REAL Generic Functions of the PDP-11 Pascal Language
Reference Manual contains the following two entries:
o COS(x) - computes the cosine of x and expresses the result in
radians.
o SIN(x) - computes the sine of x and expresses the result in
radians.
These entries should read as follows:
o COS(x) - computes the cosine of x, where x is expressed in
radians.
o SIN(x) - computes the sine of x, where x is expressed in
radians.
25. The following sentence should be added to the end of section 4.3
of the PDP-11 Pascal User's Guide.
As a general guideline, to make best use of memory, you should
declare packed record types with word aligned fields first, byte
aligned fields next, and lastly fields which will be compressed by
PDP-11 Pascal packing algorithms. algorithms.
26. The description of string constants in section 2.3.2.3 of the
PDP-11 Pascal Language Reference Manual should be altered to read
as follows.
To specify a string constant in a program, you enclose the string
in apostrophes. The length of a string constant is at least two.
A single character surrounded by apostrophes is of type CHAR, and
is not PACKED ARRAY [1..1] OF char.
27. The following description should be added to section 3.2.1 of the
PDP-11 Pascal Language Reference Manual.
All integer operations are performed in two's complement
representation modulo 32768. This condition is inherent in the
PDP-11 architecture. A consequence of the PDP-11 architecture
integer overflow is undetected in PDP-11 Pascal.
18
28. The following descriptions should be added to section 7.2 of the
PDP-11 Pascal Language Reference Manual.
.. An error occurs if x has no predecessor.
In PDP-11 Pascal boolean or integer types the predecessor of x is
always defined.
NOTE
At the values for which there is no obvious
predecessor PDP-11 Pascal exhibits these
properties:
for the integer value -maxint-1 the predecessor
is maxint;
for booleans having the value FALSE, uniquely
represented as a zero byte, the predecessor is
TRUE with an internal representation of 1.
.. An error occurs if x has no successor. In PDP-11 Pascal
boolean or integer types the successor of x is always defined.
NOTE
At the values for which there is no obvious
successor PDP-11 Pascal exhibits these properties:
for the integer value maxint the successor is
-maxint-1;
for booleans having the internal representation
255, logically TRUE, the successor is FALSE
with an internal representation of 0. (See
section C.3 of the PDP-11 Pascal User's Guide
for a discussion of boolean representation.)
PDP-11 PASCAL Version 1.3 Restrictions
The following describes known problems and restrictions in the PDP-11
PASCAL Version 1.3 compiler and OTS. Some of these items might be
corrected in either an RSX-11 Update or a future release of PDP-11
PASCAL. Workarounds for the problems have been provided whenever
possible, to lessen their impact.
19
1. Too many parameters in a write statement Write statements seem to
cause excessive recursion on the part of the optimizer. This can
result in an out-of-memory condition. The actual limit on the
number of write parameters depends on the complexity of the
individual parameters and the statement context surrounding the
write. A WRITELN of integer literals in the main program seems to
abort at over 20 parameters. More complex expressions or strings
will reduce this number. To avoid this, break up the statement
into separate WRITE statements, each with only a few of the
original parameters.
2. Value-initialized packed structures are limited to a size of 256
bytes. This means that if a value-initialized record is defined as
packed, that record can occupy only 256 bytes in memory. However,
if only one field of a record is packed, only that field is limited
to 256 bytes.
Packed structures that require more than 256 bytes of storage
should be initialized in the execution section of a program.
3. A value-initialized packed record cannot contain a nested packed
record that occupies more than one word of memory.
4. A packed array that requires 3, 5, 6, or 7 bits of storage per
element cannot be value-initialized.
5. It is illegal to refer to the fields of a structured constant.
The constant is essentially a literal, which cannot be broken into
parts.
To refer to the fields of a structured constant, assign the
constant to a structured variable and refer to the fields of the
variable.
6. A program that calls system directives must not contain global
symbols that have the same first six characters as any system
directive. The program builds correctly, but the operating system
tries to execute the variable causing an execution error.
7. Four limits are built into the PDP-11 PASCAL. If you exceed one
of these limits, you get the Compiler Limit Exceeded error. The
following is a list of these four limits and steps to take to
correct problems.
o Up to 4095 MACRO instructions are allowed per procedure block.
When a procedure is larger than 4095 instructions, divide the
procedure into several smaller procedures and recompile the
program.
o Up to 250 simultaneously active expression nodes are allowed.
When a procedure is so complex as to exceed this limit, divide
the procedure into several smaller procedures and compile the
program again.
20
o Up to 275 internal labels are allowed per procedure block. When
a procedure contains a large number of conditional statements
(IF or CASE statements), divide the procedure into several
smaller procedures or reduce the number of conditional
statements and compile the program again.
o Thirty run-time temporary locations are allowed on the internal
expression stack. When a procedure contains complicated
arithmetic expressions that use a large number of temporary
storage locations, simplify the expressions or increase the
value for NUMTMP in the compiler build file, PAS11M.CMD. Then
rebuild the compiler.
8. A compile-time error is given if an attribute is included in a
procedure or function heading of a routine that was previously
declared FORWARD. For example, the GLOBAL attribute can be placed
on a routine declared FORWARD, but it must appear in the first
declaration of the routine, not when the body of routine is
defined. The declaration should appear as follows:
[GLOBAL]PROCEDURE Test; FORWARD;
.
.
.
PROCEDURE Test;
9. Variables declared with the AUTOMATIC attribute at the program
level and referenced by a nested procedure/function at level 3 or
higher are not referenced correctly. To allow correct referencing,
pass the automatic variable as a VAR parameter from Level 2 to
Level 3, as shown in the following example. (References at Level 1
and Level 2 are handled correctly.)
PROGRAM Test ( INPUT, OUTPUT );
VAR
I : [ AUTOMATIC ] INTEGER;
PROCEDURE Test1;
PROCEDURE Test2 ( VAR J : INTEGER );
BEGIN { Test2 }
J := 3;
END; { Test2 }
BEGIN { Test1 }
21
Test2 ( I );
END; { Test1 }
BEGIN { Test }
I := 2;
Test1;
IF I = 3
THEN
WRITELN ( 'Pass ' )
ELSE
WRITELN ( 'Fail' );
END.
10. A CASE statement with an index variable of type INTEGER must have
labels whose range is not greater than 2001 elements. For example,
case label values that range from -1000 to 1000 are allowed, but
values that range from -1010 to 1000 are not. It is good practice
to use CASE indexes that are subranges of the larger types INTEGER
and CHAR. A smaller jump table is generated and correct code is
ensured.
11. The EOF test for text files other than standard INPUT files and
references to the standard INPUT file buffer are not in accordance
with the International Standards Organization (ISO) standard. Text
file buffers are not filled before an EOF test is made; therefore,
unless an explicit READLN is executed before the EOF test, EOF
returns TRUE regardless of the actual contents of the file. The
buffer of the standard INPUT file is filled only when a READLN, an
EOF, or an EOLN test precedes the referencing of INPUT. If INPUT
is referenced before the buffer is filled, the buffer remains
blank.
12. The routine name stored when traceback information (/TR:BLOCKS or
/TR:LINES) is requested is updated whenever a procedure/function is
entered. However, the routine name is not restored to its previous
value when the routine exits. Because of this, the routine name
given when a run-time error occurs is the name of the procedure or
function most recently entered, not taking into account returns
from routines. The information obtained is simply that the error
occurred sometime after a call to the routine whose name appears in
the trace information. The /TR:LINES switch generally produces
more accurate trace information than the /TR:BLOCKS switch;
although the routine name may not be recently updated, the line
number is updated with every PASCAL statement.
13. The standard INPUT and OUTPUT files are opened during task
initialization, even if they are not specified in the program
heading. Because an output file is necessary for error reporting,
22
if the standard OUTPUT file is not specified, a default output file
is provided by task initialization. This file causes the OTS
routines involved in opening files to be pulled into the task even
if no I/O is explicitly performed. Task size can be reduced by
overlaying the OTS routines that perform I/O operations.
14. You cannot reassign logical unit 5 or 6 to a device other than
the terminal or the line printer.
15. Section 1.3.3 of the "PDP-11 PASCAL Language Reference Manual"
discusses the conflict that occurs if a program or module name
duplicates a system software identifier minus its beginning dollar
sign. Usually this conflict results in a multidefined symbol at
task-build time.
When a program or module is named ERROR, the global symbol produced
for the program or module name ($ERROR) conflicts with the entry
point for the OTS routine that reports run-time errors. This
conflict is not caught at task-build time because of the
referencing mechanism for the run-time error reporting routine.
This undetected naming conflict can create an odd address or other
system trap when the program is executed.
Choose names for programs and modules with care; never use the name
ERROR.
16. The ordinal value of the elements of a PDP-11 PASCAL set are 0
through 255. Therefore, an element of a set may have a base type
that is outside the bounds of the PDP-11 PASCAL set type. In such
cases, the set operator IN produces unpredictable results. To
avoid unpredictable results, code your programs either to test for
values that are outside the bounds or to test that values are
inside the bounds. For example:
.
.
.
TYPE
a_set = SET OF 0..50;
VAR
a : a_set;
x : INTEGER;
.
.
.
IF ( x >= 0 ) AND ( X <= 255 ) THEN
IF x IN a THEN
.
.
.
23
The first IF statement checks to make sure that the ordinal value
of the element is indeed within the underlying subrange of all
Pascal sets. If this is the case, then the program checks for the
inclusion of x in a.
17. Storage is not properly allocated for nested records. When a
record is parsed, the parser allocates space and alignment
properties according to the base type. (See Sections 4.2 and 4.3
of the "PDP-11 Pascal/RSX-11 Users Guide".) Therefore, it is
possible to have a record which can be byte-aligned. For example:
.
.
.
TYPE
str = ARRAY [1..2] OF CHAR;
rec = RECORD
character : CHAR;
string : str;
END;
rec1 = RECORD
ch : CHAR;
reca : rec;
VAR
a : rec1;
.
.
.
The fields of both records, rec and rec1, are byte-aligned.
Therefore, the records are byte-aligned and their storage is
allocated on that premise.
The code generator does not know when a structure is byte-aligned.
It attempts to generate MOV instructions which start on an odd
address. The previous example might generate the following
instruction during an assignment to record arec.a and cause an odd
address trap:
MOV @R5,P$LOCL+1
To work around this restriction, declare a field of the nested
record to be of type integer, so that the record becomes
word-aligned. For example:
.
.
.
24
TYPE
str = ARRAY [1..2] OF CHAR;
rec = RECORD
character : CHAR;
string : str;
dummy : INTEGER;
END;
rec1 = RECORD
ch : CHAR;
reca : rec;
VAR
a : rec1;
.
.
.
18. Set constructors in run-time expressions can corrupt the
expression if the set constructors contain elements that are not
contiguous. For example:
PROGRAM sets (OUTPUT);
TYPE
s2 = PACKED SET OF 5..88;
VAR
x2: s2;
x1: s2;
i, j : INTEGER;
BEGIN
x2 := [5];
i := 13;
j := 18;
x1 := x2 + [i, j..21];
FOR i := 5 TO 88 DO
IF i IN x1 THEN WRITE(i:3);
END.
In the previous example, the correct output is as follows:
5 13 18 19 20 21
The actual output, however, is as follows:
5 18 19 20 21
25
To work around this restriction, split set constructors into
several smaller set constructors. For example, split [i, j..21]
into [i] + [j..21].
19. The rounding function, when used with the floating point option,
does not recognize common subexpressions (CSEs). Passing a CSE as
an argument to ROUND destroys the register storing the result of
the CSE. For example:
PROGRAM check_round (OUTPUT);
VAR
a, b : REAL;
BEGIN
a := 2.0; b := 3.56;
WRITELN ( ROUND (a+b), TRUNC (a+b) );
END.
The CSE in the previous example is the expression (a + b) and the
output is 6 6. To work around this restriction, do not pass
a CSE as an argument to the function ROUND. Assign the CSE to a
temporary variable, and pass that variable to the ROUND function.
For example:
PROGRAM check_round (OUTPUT);
VAR
a , b,d : REAL;
c : INTEGER;
BEGIN
a := 2.0; b := 3.56;
d := a + b;
WRITELN ( ROUND(d), TRUNC(d) );
END.
The previous example produces the correct results 6 5.
20. In rare instances, the Common Subexpression (CSE) context is not
broken when a procedure or function call is made. This can also
affect any variable whose storage has been optimized to a register.
The following main program and module illustrates the problem.
PROGRAM prgtst (INPUT,OUTPUT);
VAR
errflg: [GLOBAL,STATIC] INTEGER;
tstflg: INTEGER;
26
[EXTERNAL] PROCEDURE tstmdl (VAR tstflg : INTEGER); EXTERNAL;
BEGIN
errflg:=-1;
tstflg:=-9;
WRITELN (errflg, tstflg);
tstmdl (tstflg);
WRITELN (errflg, tstflg);
END.
MODULE tstmdl (INPUT,OUTPUT);
VAR errflg : [EXTERNAL] INTEGER;
[GLOBAL] PROCEDURE tstmdl (VAR tstflg : INTEGER);
BEGIN
errflg:=1;
tstflg:=9;
END;
END.
The routine, tstmdl, changes the value of the global variable,
errflg, from negative one to one. However, when the value, errflg,
is accessed after the call to the routine, tstmdl, the value is
still shown as negative one. This is the case where a variable's
storage has temporarily been optimized to a register and the
context of the optimization has not been killed before the
procedure call. To work around this restriction, declare a label
and place it immediately before the procedure call, as shown in the
following example. The label kills any optimizations up to that
point. For example:
PROGRAM prgtst (INPUT,OUTPUT);
LABEL
99;
VAR
errflg: [GLOBAL,STATIC] INTEGER;
tstflg: INTEGER;
[EXTERNAL] PROCEDURE tstmdl (VAR tstflg : INTEGER); EXTERNAL;
BEGIN
errflg:=-1;
tstflg:=-9;
WRITELN (errflg, tstflg);
27
99:
tstmdl(tstflg);
WRITELN (errflg, tstflg);
END.
21. If a local file is reset or rewritten and is not explicitly
closed before exiting the routine wherein it is declared then on
exiting the program an error message will be generated noting a
failure to close the file. A register dump will follow the error
message.
The workaround is to explicitly close any open local files. For
example
procedure t;
VAR
f : TEXT;
BEGIN { t }
rewrite(f);
.
.
.
close(f);
END; { t }
22. The compiler does not catch the error when procedures are defined
FORWARD and later redefined to be EXTERNAL.
23. The compiler inproperly handles assignments to multidimensional
packed arrays. This can unpredictably result in any of the
following behaviours:
1. The assignment is made with the right value. (it does the
right thing)
2. The assignment is made with the wrong value.
3. The assignment is made with the wrong value AND the adjacent
data is corrupted.
4. The assignment is not made AND some data someplace is
corrupted.
5. The assignment is attempted but an Access Violation results
from the code attempting to write outside the space allocated
for the program.
There are a couple ways to work around this restriction. One
alternative is to simply remove the keyword PACKED. Another is to
transform the multidimensional packed array into a singly
dimensioned packed array. For example, if the original array was
28
original = packed array [ min3..max3, min2..max2, min1..max1 ]
of char;
then define a new array in this way (newarraysize must be hand
calculated and expressed as a constant. The expression below is
given only as an aid in calculating this constant)
newarraysize = (max3-min3)(max2-min2)(max1-min1);
newarray = packed array [ 0..newarraysize ] of char;
and define the following function
function transform (x,y,z :integer) :integer;
begin
if (x < min3) or (x > max3)
or (y < min2) or (y > max2)
or (z < min1) or (z > max1)
then
begin
writeln('array subscript out of bounds');
halt;
end;
transform := (x-min3) * (max2-min2+1) * (max1-min1+1)
+ (y-min2) * (max1-min1+1)
+ (z-min1);
end;
then whenever you would need to access the element [x,y,z] from the
original array, instead access the element [transform (x,y,z)] from
the new array.
24. When using the /CD:EIS compiler switch setting on RSX-11M/M-PLUS,
a complex expression involving floating point arithmetic, many
boolean operators, and common subexpressions will cause the
compiler to generate incorrect code for some floating point
operations yielding unpredictable results.
The following illustrates an example of this behaviour
program err(output);
{ This program will print "Fail" at runtime due to }
{ improper floating point calculations if compiled }
{ with the /CD:EIS compiler switch. }
var
two : integer := 2;
six : integer := 6;
twelve : integer := 12;
begin
if (twelve/six*two < 3.9)
or (twelve/six/two > 1.1)
or (twelve div six*two <> 4)
29
or (twelve div six div two <> 1)
then
writeln('Fail')
else
writeln('Pass');
end.
There are a couple different workarounds. The first, and most
obvious, is to simply use the /CD:FPP compiler switch setting (if
your machine supports FPP instructions.)
If this alternative is not reasonable, modify the code to break up
the complexity by using temporary variables to hold intermediate
results. In the previous example, the changes might look like
this:
program err(output);
{ This program will compute all floating point results }
{ correctly and will print "Pass" at runtime }
{ regardless of the setting of the /CD compiler switch }
var
two : integer := 2;
six : integer := 6;
twelve : integer := 12;
t1,t2,t3,t4 : boolean;
begin
t1 := (twelve/six*two < 3.9);
t2 := (twelve/six/two > 1.1);
t3 := (twelve div six*two <> 4);
t4 := (twelve div six div two <> 1);
if t1 or t2 or t3 or t4 then
writeln('Fail')
else
writeln('Pass');
end.
30