p-System: Description, Background, Utilities

"I've never heard of the p-System. What is it or was it?"

"I've got a basic idea what the p-System is,
but what is or was the 'DOS-hosted' p-System?"

"I'd like an overview of the system's organisation to have an idea what I'm looking at in the manuals."

"I've heard of something called the Power System; any relation?"
Yes, during its travels from maintainer to maintainer, it was renamed "the Power System". However, this was never picked up at the Center.

p-System Utility programs for dialogue-coding work

The Center has used p-System versions from I.4 to IV.2.1; although we have a few hold-overs from previous versions, IV.2.1 is considered the "current" version to the extent that any "current" version now exists.

What is/was the p-System?

The (then UCSD) p-System is a microcomputer operating system developed starting in about 1977 (therefore before DOS, and probably before CP/M), to run, not on any physical machine in use at the time, but on a "pseudo-machine" which was emulated by an interpreter, which starts running as part of the p-System's booting. The emulator is the only part of the operating system written in the native code of the host machine. All the rest of the system is in UCSD Pascal, compiled to the so-called "p-code" instruction set of the pseudo-machine.

UCSD Pascal is a Pascal version derived from the "P2" portable compiler of Urs Armann by the p-System project at UCSD, under Prof. Kenneth Bowles, and with consultation from the Center's personnel at the time, notably Stephen Franklin and Alfred Bork. From the then-developing specifications for the Ada language, it derived the concept of separately compiled modules with explicit and distinct public declarations; UCSD called them units, and they were later inherited by other Pascals such as Turbo, from Borland, and Microsoft.

Manuals for the first versions that the Center received, versions I.4 and I.5, provide a view of the architecture of the first versions of the p-machine and of the operating system; they may also provide necessary information should transfer be undertaken of projects funded at the Center in the early 1980's that were never transferred to 5.25" or 3.5" discs.

The objective was to create an operating system that was portable across a variety of machines of quite different characteristics -- this was several years before the IBM PC or the Macintosh or Amiga first arrived, and microcomputers tended to show considerably more variety than at present in their choices of construction and architectures. They were also, of course, far more restricted in speed and resources. CPU speeds even as high as 4MHz had not yet been attained, and the amount of memory on the largest microcomputer available was 64K (reduced to 56K because of memory reserved for terminal emulation). Hard discs were not yet available for micros.

The p-machine therefore had to be:

It succeeded in both objectives: The p-System is also capable of supporting code in the native instruction set of the host machine -- it is marked as such in the structure of the p-code segment that contains it, and the p-machine emulator calls it as a subroutine (if its code is executable on the current machine). It is created with the p-System's so-called adaptable assembler, for which opcode and syntax information is supplied in pairs of files specific to the intended target machines. Although it is of course wiser to avoid assembly code wherever possible, some usages such as graphics require a certain minimum execution speed which only assembly can provide.

However, despite this occasional need for speed optimisation, the common view that interpretation is extremely slow tends to be exaggerated in the case of the p-System. It is probably not, for instance, to be compared to the slowness of LISP or ordinary BASIC interpreters.

The DOS-hosted p-System:

Since, on real machine, the p-System is emulated, it was reasonable to create a version of it to run as an application program under operating systems that always run in native code. Such versions exist for at least UNIX, DOS, and VAX VMS. There are extremely few differences, perceptible to the user, from the autonomous version:
The DOS-hosted p-System is run by executing PSYSTEM.COM (experienced DOS users will note the age of this executable by the fact that it is a .COM file, rather than an .EXE), with (almost) arbitrarily many virtual volume files as parameters. The first will be used to boot the system from, so it must contain a bootable system configuration (see the manuals). It will be designated the root volume, and at least at initialisation, the prefixed volume. Other virtual volume parameters will also have the volumes they contain mounted on-line.

If the p-System's file SYSTEM.CONFIG has the appropriate drivers installed, the DOS-hosted p-System, when run on a PC whose hard drive contains autonomous p-System partitions, will mount each partition in addition to mounting the virtual volume files.

An obvious usage of virtual volume files is to place a common boot volume file, and a common volume file of tools and library units, onto a central file server from which all PC's using the p-System can use them to boot.

Educational Technology Center
Dept. of Information and Computer Science,
Univerity of California, Irvine
Irvine, CA, USA