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.
A translator for converting keyed source files, using PDisplay capabilities,
into binary keyed files. An integral component of the Keyed
File system.
Substring matching across multiple files.
Fgrep, a substring matching program based loosely on the UNIX
grep family of programs. Like UNIX's fgrep, it does not support
regular expression matching.
Support for accented, technical, and other specialised character fonts
Semi-automated generation of documentation for directories
Formatted file listings (documents, programs, etc.)
Description of the so-called Super Typer, intended for pre-network
era printing of
large programs with many include files. The setup section of the program
is discussed separately.
This documentation may be useful when porting old p-System sources
to current
environments, if there is a need to understand the facilities that
were in use at the time.
- Many others written over several years by various coders.
Exploration of the
TOOLS.VOL virtual volume is
recommended.
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:
- maximally independent of (or reconfigurable to) the idiosyncracies
of specific hardware;
- very conservative with machine resources.
It succeeded in both objectives:
- the Center has had releases of the p-System running on the DEC LSI-11, the
Zilog Z80, the Motorola 68000, and almost every member of the Intel
80*86 family from the 8088 to the 80386. Compiled object code, whether in
the operating system or part of user-developed programs such as the
Center's, having been compiled, for instance, on the 68000 could then
be moved to, say, an 8088 and execute with no apparent awareness of the
difference -- presuming that it did not attempt to use hardware
features particular to the original machine.
-
The very compact instruction set architecture (the most commonly used
instructions, with their most frequent parameter values, are condensed
into 1 byte each) both lets a reasonable set of executable code files
reside on a single floppy -- even floppies of approximately 200 to 300 K,
common at that time -- and lets an optimal set of executable code
segments reside in even small memory. This became even more true when
version IV of the p-System restructured it to use dynamic linking, so
that programs on disc no longer had to have copies of library module
code linked into them statically.
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.
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:
- A new file type is created in the
host operating system, whose
internal structure simulates a p-System blocked volume; it is
therefore called a virtual volume file.
- Units to support communications and data exchange between the
p-System and the host operating system are added to the operating
system, and (at least in the case of DOS) a special filer,
DOSFILER.CODE, provides manipulation of DOS directories,
and also the creation, mounting, and dismounting of DOS virtual volume
files.
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.