RSTS/E & PDP-11 Layered Products

[Bill Gunshannon]

Two things.

First, I just re-read the Mentec Licens for the Emulator and it states
the any version of RSTS up to V9.3 is legal. I think I have a V9.something
tape here somewhere. If it is 9.3 or less would there be interest in making
this available?? If so, could someone tell me the best way to take the
two tapes and make them into virtual tapes that could be used to boot and
install on SIMH??

And second, we come tot he layered products issue. I have a copy of Fortran
from RT-11 on RX02 floating around (I was sorting through old 8" disks over
the weekend.) Any interest in this as well??

And let's take this even further. has anyone ever considered trying to
locate/contact any of the people from the old PDP-11 Sourcebook (I have
the 1985 edition) to see if any of the old PDP software might be made
available?? I have found COBOL+ and OMSI Pascal disks in my stash as
well. Assuming bit-rot hasn't made them unreadable, it would be neat to
have these made available as well. I don't know the status of the company
that did COBOL+, but I seem to remember that OMSI was bought, perhaps even
by DEC.

Comments anyone??

bill

--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bi...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>

[Bob Schor]

Bill Gunshannon wrote:

>
> And let's take this even further. has anyone ever considered trying to
> locate/contact any of the people from the old PDP-11 Sourcebook (I have
> the 1985 edition) to see if any of the old PDP software might be made
> available?? I have found COBOL+ and OMSI Pascal disks in my stash as
> well. Assuming bit-rot hasn't made them unreadable, it would be neat to
> have these made available as well. I don't know the status of the company
> that did COBOL+, but I seem to remember that OMSI was bought, perhaps even
> by DEC.
>
> Comments anyone??
>

I know about OMSI. The Oregon Museum of Science and Industry supported a group
that made an EXCELLENT Pascal (ISO-compliant) Pascal compiler that ran on RT-11,
RSX, VMS, and (I think) IAS. The group later changed its name to Oregon
Software, and came out with Pascal-2, an optimizing version of their compiler.
[I believe they had a few other products, as well].

At some point in the mid-to-late 80's, the company was either acquired (or the
product was acquired) by a company called TauMetric. A few years after that,
TauMetric ceased to exist.

While TauMetric was still in existance, I helped them read some source tapes of
the PDP/VMS Pascal software code base. They also had a port to the PC, but as I
understand it, TauMetric did not have rights to the PC product (or, in any case,
they didn't send me the tapes).

At one point in the late 70's or early 80's, DEC came out with a product called
MicroPower Pascal. It is my understanding that this is essentially Oregon
Software's Pascal-2, with some "hooks" and additions to extend the language in
certain ways.

Bob Schor
Pascal Enthusiast
(I still have the Pascal-2 products running on my PDP-11 systems)

[swo...@speakeasy.org]

In alt.sys.pdp11 Bill Gunshannon <bi...@triangle.cs.uofs.edu> wrote:
> First, I just re-read the Mentec Licens for the Emulator and it states
> the any version of RSTS up to V9.3 is legal. I think I have a V9.something
> tape here somewhere. If it is 9.3 or less would there be interest in making
> this available?? If so, could someone tell me the best way to take the
> two tapes and make them into virtual tapes that could be used to boot and
> install on SIMH??

Bill,

You can contact Tim Shoppia for how to make them into virtual tapes.
Check http://www.trailing-edge.com for more information. I know that
software to extract data from tapes into virtual tapes called 'vmstcpe'
or so.

-- Tim Stark

--
Timothy Stark <>< Inet: swo...@speakeasy.org
--------------------------------------------------------------------------
"For God so loved the world, that he gave his only begotten Son, that
whosoever believeth in him should not perish, but have everlasting life.
Amen." -- John 3:16 (King James Version Bible)

[Jerry Hudgins]

Bob Schor wrote:
>
> I know about OMSI. The Oregon Museum of Science and Industry supported a
> group that made an EXCELLENT Pascal (ISO-compliant) Pascal compiler that
> ran on RT-11, RSX, VMS, and (I think) IAS. The group later changed its
> name to Oregon Software, and came out with Pascal-2, an optimizing version
> of their compiler.

I used Pascal-2 on RSX, and agree that it was excellent. It was vastly
better than the RSX Pascal product being marketed by Digital at the
time.

> At one point in the late 70's or early 80's, DEC came out with a product
> called MicroPower Pascal. It is my understanding that this is essentially
> Oregon Software's Pascal-2, with some "hooks" and additions to extend the
> language in certain ways.

Having used both products, I can assure you that they were very
different
indeed (at least from the user's standpoint). The MPP compiler supplied
along with the MicroPower embedded kernel probably had its origins in
the
VMS and PRO Pascal families, if memory is serving me correctly. It had
numerous extensions to allow practical realtime coding, but otherwise
more closely resembled PRO Pascal than Pascal-2.

I liked the MicroPower product, though I did most of my MPP coding in
MACRO-11 rather than Pascal. It performed well, produced ROMable code,
and had a decent debugger (compared to what was available for RSX,
anyway).
Conceptually, it was to RSX what VAXELN was to VMS. Indeed, I ended up
porting most of my MPP stuff to ELN eventually.

-jch

[K.J. Seefried]

On Mon, 07 Jan 2002 17:31:07 -0500, Bob Schor <bsc...@pitt.edu> wrote:
>The group later changed its name to Oregon
>Software, and came out with Pascal-2, an optimizing version of their compiler.
>[I believe they had a few other products, as well].
>

I remeber Oregon & Pascal-2. Very nice stuff. A language definition
would be interesting to see after all these years.

Ken

[Douglas A. Gwyn]

Bill Gunshannon wrote:
> I have a copy of Fortran from RT-11 on RX02 floating around ...

> Any interest in this as well??

I could sure use that!

[Don Baccus]

20 years later ... I was a co-founder of Oregon Software and the primary author of our Pascal-2 compiler (and co-author of the earlier Pascal-1 compiler).

MicroPower Pascal was indeed based on Pascal-2, and I consulted with the group within DEC for about a year as part of the deal between the two companies. I had nothing to do with the design of MicroPower Pascal but did help with implementation of various aspects of it.

Ironic to read the comment that DEC's RSX Pascal product was inferior to Pascal-2 because it was based on Pascal-2 (part of the same deal with DEC). When the product team told me some of the changes they were making I bit my tongue and shut up.

After all these years I don't expect a response but if by any chance anyone does, I have a lot more information I can share ...

[Johnny Billquist]

Don, this is interesting indeed. First of all, I might have the last
release done of OMSI Pascal-2 for RSX (version 2.1E). I needed to patch
one thing, since it didn't work out of the box on newer versions of RSX.
The problem is just a change of attributes and size of a psect, so it
wasn't too difficult to fix.

Anyway, I also did look at DEC's own Pascal for RSX, which was
discontinued long before the demise of RSX, and at least from a user
point of view, they are very different. Both in capabilities, syntax of
things, what options you can control, and how code it generates. So it
does really surprise me to hear that they were supposed to be related.
Are you sure about this? DEC did have several Pascal compilers... MPP
was not the same as the RSX Pascal at least. The RSX Pascal compiler
distribution tapes are available online if anyone wants to look at that.

Anyway, one question is obviously if you know if any sources are still
around somewhere? I'm trying to preserve RSX software as much as I can,
but in general sources for layered software have turned out to be a
difficult problem.

Johnny

[Don Baccus]

Yes, I am sure. I was one of three negotiators for Oregon Software for the deal, and DEC looked at RSX Pascal as being more important than MicroPower Pascal. They modified the compiler heavily for RSX Pascal, though, as I said earlier, when they told me some of the stuff they were doing I bit my tongue.

I'll write something longer tomorrow ...

[Johnny Billquist]

On 2022-01-18 03:34, Don Baccus wrote:

> "Are you sure about this?"
>
> Yes, I am sure. I was one of three negotiators for Oregon Software for the deal, and DEC looked at RSX Pascal as being more important than MicroPower Pascal. They modified the compiler heavily for RSX Pascal, though, as I said earlier, when they told me some of the stuff they were doing I bit my tongue.
>
> I'll write something longer tomorrow ...

Thanks. Looking forward to whatever you can tell.

Anyway, 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.

But it's really very VAX PASCAL compatible, with a completely different
syntax than OMSI Pascal for lots of rather core things. I'm amazed that
it's the same codebase. Not to mention that it's pretty bad. I don't
even install it usually. Just have OMSI Pascal installed, which is way
better (even if it is the same codebase :-D ).

Johnny

[Don Baccus]

On Monday, January 17, 2022 at 6:41:53 PM UTC-8, Johnny Billquist wrote:

> Anyway, 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.

>
> But 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.

Of 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.

> I'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++.

The 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.

> even 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.

[Don Baccus]

On Monday, January 7, 2002 at 2:31:07 PM UTC-8, Bob Schor wrote:

I remember Bob Schor well ... is he still around?

> I know about OMSI. The Oregon Museum of Science and Industry supported a group
> that made an EXCELLENT Pascal (ISO-compliant) Pascal compiler that ran on RT-11,
> RSX, VMS, and (I think) IAS. The group later changed its name to Oregon
> Software, and came out with Pascal-2, an optimizing version of their compiler.
> [I believe they had a few other products, as well].

We started as a group of high schoolers at OMSI, selling a (largely) RSTS/E Basic compatible Basic for the PDP-8 (written by me and Gerd Hoeren), a PDP-8 floating point library written by Wayne Davison that was about twice as fast as the standard DEC one with more accurate transcendental functions, hacked an open source TECO editor to run under PS/8-OS/8 which became the basis of DEC's OS/8 Teco. I also wrote a PDP-8 kernal implementing virtualization of memory allocation and I/O service to timeshare OS/8 for the company (ESI) that later paid for the development of what became OMSI Pascal-1.

Most of the above will be of little/no interest to PDP-11 people but it helps explain why we left the museum and formed Oregon Minicomputer Software, Inc (also OMSI in acronym form), with the name later changed to Oregon Software to get rid of any confusion with the Museum itself.

We essentially brought in too much money and spun off. We were actually the second company to spin off from the museum, the first one produced educational products.

For the PDP-11 our other best-known product (after Pascal) was RT-11 for RSTS/E. RSTS/E was essentially a general purpose operating system but sold configured to run RSTS/E Basic only. We provided RT-11 with the native device drivers replaced with device drivers etc that worked with the RSTS/E. Pascal-2 was developed using this environment (couldn't stand RSX-11) on an 11/45 with a third-party memory cache. We ended up supporting RSX-11, of course. We also played with Unix on that machine starting in 1975? 1976? back when the terminal device driver was half-duplex and compatible with Multics. We got sources (because we were still at the museum, i.e. non-profit) and the first thing I did was to rewrite the terminal device driver to be full duplex and compatible with DEC conventions (i.e. delete/rubout would shew\we\ow error corrections as you did them as opposed to the original errrr##or correction of the original half-duplex driver).

> At some point in the mid-to-late 80's, the company was either acquired (or the
> product was acquired) by a company called TauMetric. A few years after that,
> TauMetric ceased to exist.

TauMetric was started by one of our employees, Michael Ball, who hailed from San Diego and couldn't stand the rain in Portland after having lived here a few years.

They developed our C/C++ front end under contract for Oregon Software. They retained rights to that front end but never bought Oregon Software or its assets. We had a friendly relationship, I ported their C++ front end to MIPS under contract to MIPS though it never saw the light of day because Silicon Graphics bought MIPS and killed the project which was just about to enter beta testing. After TauMetric died, Mike Ball when on to Sun Microsystems as part of the Cafe project which gave rise to Java.

> While TauMetric was still in existance, I helped them read some source tapes of
> the PDP/VMS Pascal software code base. They also had a port to the PC, but as I
> understand it, TauMetric did not have rights to the PC product (or, in any case,
> they didn't send me the tapes).

I had no idea that Bob Schor was involved in this :) Since TauMetric was contracted to Oregon Software to write our C/C++ front end I have no idea why they had to reach out to Bob to read source tapes, but as I said above, I was no longer running the company at this time. TauMetric was just two people so probably didn't have a compatible disk drive, is my guess - disk drives were expensive in those days.

I helped TauMetric figure out how to detect C constructs like "goto" statements into the middle of blocks that required the turning off of various optimizations and the like but wasn't involved otherwise.

> (I still have the Pascal-2 products running on my PDP-11 systems)

That makes me happy though the note is 20 years old! :)

[Don Baccus]

On Monday, January 17, 2022 at 4:33:59 PM UTC-8, Johnny Billquist wrote:

> Anyway, one question is obviously if you know if any sources are still
> around somewhere? I'm trying to preserve RSX software as much as I can,
> but in general sources for layered software have turned out to be a
> difficult problem.

Unfortunately I don't know of any sources being available for this. It didn't dawn on me to keep a copy for my personal archives. Oregon Software died in 1991 and time had passed us by. The compiler technology had, after all, been developed for the itty-bitty PDP-11 and this was reflected in its structure, the optimizations performed, etc. It was a four-pass compiler (lexical processor, syntax/semantic analyzer, optimizer, code generator) on the PDP-11 and I did have the foresight to write the intermediate language passed from pass to pass in such a way that on the VAX and other machines with amount of memory I was able to reconfigure it as a two-pass compiler (lexical processor+syntax/semantic analyzer and optimizer/code generator) but the overall structure was such that it was kinda difficult to build on and improve.

So by then I had moved on. Did some compiler work for another decade or so but not using the Oregon Software compiler technology other than a couple of projects porting the TauMetric C++ front end to integrate with backends developed by other companies.

Probably too much information ...

[Johnny Billquist]

On 2022-01-18 16:45, Don Baccus wrote:
> On Monday, January 17, 2022 at 6:41:53 PM UTC-8, Johnny Billquist wrote:
>
>> Anyway, 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.

>> But 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.

> Of 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.

>> I'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.

> The 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.
>
>> even 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

>= 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

>MAC 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

[Don Baccus]

Thanks! Many of these are obviously due to extensions/changes they made to the compiler.

One hint it is based on Pascal-2 is where they comment on a problem that "appears to be caused by blah blah in the optimizer", i.e. they didn't understand the cause, because the optimizer was quite complex and a bit tricky.

Some of the bugs that are listed were probably ours (OK, mine :) ) in the relatively early version they built their product on. Oddly, they never sought any consulting help with us in identifying or fixing bugs so we went off independently finding and fixing them. Unlike the MicroPower Pascal group.

I see one "bug" they list that really isn't and which I guess helps to underscore our differing philosophy. We treated char as being an unsigned value (they are not, in Pascal, simply baby integers). They "fixed" that if I read correctly.

If I had infinite time it might be interesting to see which of the crashing and looping examples exist in the later version of Pascal-2 you have available. Then again, it might be embarrassing if they still exist :)

[Johnny Billquist]

On 2022-01-18 20:34, Don Baccus wrote:
>
> Thanks! Many of these are obviously due to extensions/changes they made to the compiler.

My pleasure. Always nice to able to provide some info.

> One hint it is based on Pascal-2 is where they comment on a problem that "appears to be caused by blah blah in the optimizer", i.e. they didn't understand the cause, because the optimizer was quite complex and a bit tricky.
>
> Some of the bugs that are listed were probably ours (OK, mine :) ) in the relatively early version they built their product on. Oddly, they never sought any consulting help with us in identifying or fixing bugs so we went off independently finding and fixing them. Unlike the MicroPower Pascal group.

That is an interesting observation. I wonder why they never came back to
you.
And also, DEC retired PDP-11 PASCAL/RSX after release 1.3 which came out
Oct 1990.

On that, MicroPower Pascal was also retired after version 2.5, which
came out Sep 1989.

> I see one "bug" they list that really isn't and which I guess helps to underscore our differing philosophy. We treated char as being an unsigned value (they are not, in Pascal, simply baby integers). They "fixed" that if I read correctly.
>
> If I had infinite time it might be interesting to see which of the crashing and looping examples exist in the later version of Pascal-2 you have available. Then again, it might be embarrassing if they still exist :)

Well, just in case you want to play, you can telnet to mim.stupi.net,
and login as guest with password guest. Pascal-2 is installed as PAS,
and you can play around as much as you want...

Johnny

[Don Baccus]

Could move this to private e-mail I suppose but it only allows "reply to all" not "reply to author" here ...

Anyway

tkb hello=hello:[1,1]paslib/lb

Fails with paslib.olb not found

so I've got the command wrong ...

hint?

[Johnny Billquist]

tkb hello=hello,lb:[1,1]paslib/lb

but the paslib.olb in lb:[1,1] is probably not what you should use.

See HELP LOCAL PASCAL LINK

but in short, there is a logical name for the pascal library, which is
just paslib, so even simpler:

tkb hello=hello,paslib/lb

should make you happy...

(I'm trying to remember what the lb:[1,1]paslib.olb is from. Might be
similar/same to PAS:PASLIB.OLB, which is where PASLIB points to.)

Johnny

[Don Baccus]

OK that works I copied the command line wrong from our manual, sigh. Well, I did my best to stay away from RSX-11M, preferring RT-11 as my work environment using our RT-11 RTS under RSTS/E (later we might've switched to DEC's).

Is this a simulated box???

[Johnny Billquist]

On 2022-01-19 16:31, Don Baccus wrote:
> OK that works I copied the command line wrong from our manual, sigh. Well, I did my best to stay away from RSX-11M, preferring RT-11 as my work environment using our RT-11 RTS under RSTS/E (later we might've switched to DEC's).

RSX is a blast if you ask me, but everyone have their own preferences. :-)

> Is this a simulated box???

Yes. In fact it's a simulated PDP-11/74 (the multiprocessor PDP-11 that
never was, officially).

Johnny

[Don Baccus]

After I wrote that I saw the reference to dbit. Cool.

RSX-11M was a very good real time system and a huge improvement over RSX-11D. I hadn't realized that RSX-11M had file versioning, I thought that came in with VMS. That's a cool discovery.

Pascal-1 was written on an 11/05 so RT-11 was the only real choice. And I came from a background of using OS/8. As I mentioned above we wrote an RT-11 RTS for RSTS/E and RSTS/E was a fine straightforward timesharing system. We didn't do an RTS for RSX. Of course later DEC provided RT-11 and RSX-11 RTS's for RSTS. Our products had to support RT-11 with no memory management hardware so it made a certain amount of sense to develop them for that minimal system. If Pascal-2 ran on that it wasn't a problem to get it to run on RSX-11 with its fancy overlay capabilities etc.

Anyway E11 looks like a cool piece of software and I'm enjoying playing with Pascal-2 and ... TECO ... amazing how quickly TECO has come back to me after decades. Looking at macro output I remember that I never put effort into optimizing conformant arrays which brings back memories of how the code generator just barely fit into the available memory space and how crunched and hacked it was because of this. When we moved on to 32-bit machines the code generator design was kept but the data structures were made much more programmer-friendly as there wasn't the same need to squeeze every byte possible out of the memory footprint.

Thanks for all this, dude. I haven't really thought of Pascal-2 often for many, many years. I'd forgotten what a complete suite of tools we supplied with the product, some developed in-house (I wrote the string package), others derived from open source code (before that term had been invented) provided by friends in the Pascal development community.

I'm curious as to where you managed to find the Pascal-2 release. It was not one sold to a customer (note it identifies it as being license to Oregon Software, license #1-1). I'm guessing one of our employees had more sense than me and built and saved a release disk :)

[Johnny Billquist]

On 2022-01-19 23:43, Don Baccus wrote:
> On Wednesday, January 19, 2022 at 1:59:04 PM UTC-8, Johnny Billquist wrote:
>> On 2022-01-19 16:31, Don Baccus wrote:
>>> OK that works I copied the command line wrong from our manual, sigh. Well, I did my best to stay away from RSX-11M, preferring RT-11 as my work environment using our RT-11 RTS under RSTS/E (later we might've switched to DEC's).
>> RSX is a blast if you ask me, but everyone have their own preferences. :-)
>>> Is this a simulated box???
>> Yes. In fact it's a simulated PDP-11/74 (the multiprocessor PDP-11 that
>> never was, officially).
>>
>> Johnny
>
> After I wrote that I saw the reference to dbit. Cool.

Yeah. I've been talking (and sometimes working) a lot with John Wilson,
who is responsible for e11.

> RSX-11M was a very good real time system and a huge improvement over RSX-11D. I hadn't realized that RSX-11M had file versioning, I thought that came in with VMS. That's a cool discovery.

I believe even -11D had that. It inherent in the ODS-1 file structure,
which I think all of them used. But RSX-11M-Plus is a pretty big step
from -11D or -11M. Very fancy...

> Pascal-1 was written on an 11/05 so RT-11 was the only real choice. And I came from a background of using OS/8. As I mentioned above we wrote an RT-11 RTS for RSTS/E and RSTS/E was a fine straightforward timesharing system. We didn't do an RTS for RSX. Of course later DEC provided RT-11 and RSX-11 RTS's for RSTS. Our products had to support RT-11 with no memory management hardware so it made a certain amount of sense to develop them for that minimal system. If Pascal-2 ran on that it wasn't a problem to get it to run on RSX-11 with its fancy overlay capabilities etc.

Totally understandable. I'm actually a bit surprised/impressed that you
got it all working under RT-11 with no MMU. That's a very limited
environment.

> Anyway E11 looks like a cool piece of software and I'm enjoying playing with Pascal-2 and ... TECO ... amazing how quickly TECO has come back to me after decades. Looking at macro output I remember that I never put effort into optimizing conformant arrays which brings back memories of how the code generator just barely fit into the available memory space and how crunched and hacked it was because of this. When we moved on to 32-bit machines the code generator design was kept but the data structures were made much more programmer-friendly as there wasn't the same need to squeeze every byte possible out of the memory footprint.

Well, with "modern" RSX-11M-Plus, not only do you have split I/D-space,
giving you a lot more memory, but also supervisor mode libraries,
meaning even more stuff gets out of the way, and you end up with quite a
lot of memory for whatever you want to do.

> Thanks for all this, dude. I haven't really thought of Pascal-2 often for many, many years. I'd forgotten what a complete suite of tools we supplied with the product, some developed in-house (I wrote the string package), others derived from open source code (before that term had been invented) provided by friends in the Pascal development community.

My pleasure.

> I'm curious as to where you managed to find the Pascal-2 release. It was not one sold to a customer (note it identifies it as being license to Oregon Software, license #1-1). I'm guessing one of our employees had more sense than me and built and saved a release disk :)

As far as I know, it was sold. It was (and possibly still is) running at
a company in Sweden that have the distribution, manuals, and all. I
could ask them in case you really want to know, but I've had my hands on
the official distribution tape that the company have.

But I don't know the back history. I know some bits and pieces, which I
can share direct with you, but if you say that normally a distribution
would be cut with license information built into the binaries, then it
appears that someone skipped that along the way.

But there is nothing about licenses anywhere during the generation or
installation.

You can see a bit of stuff at MIM::DU:[ORPAS]

Johnny

[Johnny Billquist]

Almost forgot. You can also see some of the documentation at
http://mim.update.uu.se/manuals/layered/

Johnny

[Don Baccus]

I found an rsx-11 pascal-2 manual online. Now I need to look at an example using the debugger, gets "too many files" open, need to tell tkb to allow more files :) Not many language processing systems that were true compilers had source-level debuggers or profilers back then.

I don't think the installation process would've mentioned licensing. Users signed a license agreement before shipping, this was before shrink wrap licenses were used (and their legality established). We'd then build the customer media.

As far as the RT-11 goes, our contract required that the compiler be able to compile itself on an RT-11 with 56KB and ... and ... two floppy disks for disk storage. No hard disk. Seriously. I was almost surprised that the floppies didn't wear out by the time the compiler was done doing so, it took hours.

I think they actually tried to support that configuration for MicroPower Pascal at first but I think they dropped that eventually. I sure lobbied for them to do so every month when I went to the Mill to spend a week with the MPP development group.

[Don Baccus]

So I went to the layered software documentation page you shared and the checklist for the distribution has everything checked except the license agreement, which was not included.

There was a company in Sweden that sold our software there, I would guess that this was a copy that originally was sent to them for their own use in demoing it etc.

[Don Baccus]

On Wednesday, January 19, 2022 at 3:55:16 PM UTC-8, Don Baccus wrote:

Ah, the installation guide says that the software is preliminary in nature.

A beta release, in today's terminology. So perhaps it was a customer that was doing testing for us.

[Johnny Billquist]

Right. I also noticed that now that I was looking.

> There was a company in Sweden that sold our software there, I would guess that this was a copy that originally was sent to them for their own use in demoing it etc.

And funnily enough, this is in Sweden. :-)
So I guess that company was involved.

Johnny

[Johnny Billquist]

On 2022-01-20 01:01, Don Baccus wrote:
> Ah, the installation guide says that the software is preliminary in nature.
>
> A beta release, in today's terminology. So perhaps it was a customer that was doing testing for us.

A beta that have been in production for the last 30 years or so. :-)

Johnny

[Richard Kerry]

It is very interesting to hear about the history of Oregon Pascal-2. I used it for many years (68000 cross-compiler variant) at a previous employer.
Does anyone have any source code? Does anyone know the current state of ownership/licensing?

Regards,
Richard.

[Don Baccus]

Ownership/licensing ... none of the ownership entities legally exist any more. As the principle author and co-founder (and for several years COO) of Oregon Software, if I had sources I'd release them.

But none exist. Not only for the PDP-11 native version, but none of the others AFAIK. I'm trying to find them but I'm not optimistic. We had front ends for Modula-2 and C/C++ and backends for the PDP-11 (Pascal only), a 16-bit Honeywell minicomputer (done under contract with Honeywell), MC68000 (my favorite microprocessor for a long time), VAX, NS32000, and x86 (my least favorite microprocessor for ever and ever and ever ...). I wrote the Pascal and Modula-2 front ends and all of the code generators other than the X86 though I ended up helping out with some optimization schemes.

All gone AFAIK.

The PDP-11 version was the least capable of the various backends, which I forked early on. Pascal-2 was required to self-compile on flat memory machines with no I/D separation and barely fit. As mentioned above, our contract with DEC required this to work on a machine with just two floppies though once it passed that test, I doubt that anyone ran the software in that environment. Every improvement in code generation had to pay off with the new code resulting in a compiled code generator no longer than the version without the improvement, a bit of a catch-22. On bigger machines the code generator could be larger and therefore more improvements could be implemented.

But looking at the code it generates, compiling examples on the pubic simulated RSX system discussed by Johnny above ... it wasn't bad. Not bad at all ...

Motorola was a fun company to work with and the MC68000 an amazing microprocessor when it was introduced.

I really wish I had sources to just one of these old Oregon Software products ...

[Dennis Boone]

> a 16-bit Honeywell minicomputer (done under contract with Honeywell)

Would this have been the 316/516/et al family?

De

[Don Baccus]

Googling informs me that they were the Level 6 (renamed DPS 6) 16-bit series.

Word rather than byte addressed so 128KB available rather than the 56KB on a non-I/D PDP-11.

I enjoyed that, believe me! I forget what our minimum memory target was for the compiler but for self-compilation it could use more than whatever minimum they might've imposed.