Subject: FAQ Multics Features
Date: 1 Jan 1996 10:02:30 -0800
Summary: General information about Multics features.

archive-name: multics/features

06/01/94 THVV split out features from general
06/01/94 THVV added LISP info from BSG. (Wish everything were described
              to this level of detail.  Help me out, folks.)
02/21/95 THVV added some clarifications while reformatting.
09/05/95 THVV corrections about COBOL from Otto Newman & Richard Barnes.
10/05/95 THVV added info on DTSS languages from Paul Karger

Please post updates to alt.os.multics or mail to <thvv@best.com>
====================================================================
1.      Multics Software Features
1.1.      Hierarchical file system
I think that Multics was the first to provide a hierarchical file
system.  The influence of that innovation can be found in virtually every
modern operating system, including MacOS, DOS and Windows. [JHS]

1.2.      Virtual memory management
Paul Green posted a description in May 93.

1.3.      Dynamic linking
Multics needed no loader.  Write a procedure, say joe, & compile: 
suppose the resulting binary refers to an external subroutine called 
fred.  You can run joe by just typing its name.  The command processor 
launches it by just finding the segment joe, adding it to the user 
process's address space, and jumping to the entrypoint.  Fred may not 
even exist, and if joe never calls it, no problem.  If joe does call 
fred, a linkage fault occurs.  The system linkage fault handler searches 
for a file named fred, adds it to the address space & fixes the linkage 
to go fast next time, and continues.  If fred's not found, the user gets 
a fault message, and can quickly write a fred, compile it, and then 
continue execution of joe, which will then find fred.  <<more: binder, 
run units, use command>>

1.4.      Scheduler
The Multics scheduler began as a Greenberger-Corbato exponential 
scheduler similar to that in CTSS.  About 1976 it was replaced by a 
virtual deadline scheduler which supported specification of desired 
realtime response (N milliseconds in M) for system processes such as 
printer daemons, and supported "work classes" that could be guaranteed 
percentages of the system's CPU resource under load (e.g., "Give 
Engineering 17% and Humanities 12%").  Load control groups defined by 
the answering service were mapped into work classes via the Master Group 
Table (MGT).

1.5. Instrumentation
There were many metering commands, such as file_system_meters, 
traffic_control_meters, pre_page_meters, device_meters, tty_meters, 
page_trace, trace, meter_gate, meter_signal, alarm_clock_meters, 
vtoc_buffer_meters, total_time_meters, the ready message, and the script 
driver.  The microsecond hardware clock made it easy to instrument code.  
Almost all subsystems had metering built in, running all the time; the 
commands just displayed the internal counters.  The standard procedure 
for installing a new system release included running a 60-minute 
performance benchmark.

1.6.      Accounting & administration
Multics provided a set of applications for printing monthly usage 
reports and bills for timesharing users.  CPU usage was recorded to the 
microsecond; memory residence to the page-millisecond (this unit was 
called the "Frankston" after its initial implementer), disk storage 
residence to the page-second.  Individual users had quotas and dollar 
limits, administered by group administrators and project administrators.

1.7.      Languages
1.7.1.  EPL - Early PL/I.  Bell Labs contracted with Digitek in 1967 or 
so for a PL/I compiler, but they didn't deliver.  A BTL team led by Doug 
McIlroy and Bob Morris created the EPL compiler using McClure's TMG 
compiler-compiler, macro'd over from the CDC 1604 -> 7090 -> 7094 -> 635 
-> 645.  It was very slow; we joked that one more port would kill it.

1.7.2.  EPLBSA - EPL Bootstrap Assembler.  A GE team under Tom Kinhan 
was working on a very fancy full-macro assembler, but we needed an 
interim assembler in a hurry, so Bill Poduska wrote EPLBSA.  EPL 
compiled into EPLBSA and was then assembled.

1.7.3.  PL/I - there were several versions.  The "version 2" compiler 
was robust, efficient, and a clean implementation of the language.  
Almost all of the operating system was written in PL/I.  Compiled 
directly to binary.  Language defined by IBM.  Few other languages with 
pointers available at the time we were choosing a language.  (CTSS used 
MAD for some complex supervisor routines, like the scheduler, and AED-0 
for one routine.) History: EPL, v1pl1, v2pl1.  Language features.  ANSI.  
Use of Multics architecture: stack, segmentation.  Special Multics 
extensions to PL/I language: ptr, baseptr, stac.  <<more, see RAF paper 
on PL/I, Corby's PL/I tool paper>>

1.7.4.  ALM - Assembly Language for Multics.  A clean, spare assembler.  
Used for programs that needed ultimate efficiency or that issued 
privileged instructions.

Nathan Adleman, Richard Gumpertz, and Paul Green converted
EPLBSA from GE FORTRAN to Multics PL/I in 1969-1970.  
Steve Webber wrote a stand-alone macro processor, mexp, and Bernie
Greenberg integrated it into ALM in 1977 or so.

1.7.5.  COBOL - Done by a group at Honeywell Billerica including 
Otto Newman, George Mercuri, and Frank Helwig; they 
ported an existing front-end and wrote a code generator for it.
Made good use of the EIS instruction set.

1.7.6.  FORTRAN - Multics had three FORTRAN compilers.
Version 1 FORTRAN was written using POPS by Ke Shih at GE/CISL.

The version 2 compiler was written in <a href="mgp.html#pl1">PL/I</a>
at CISL, and shared a back end code generator with the PL/I compiler.

The last Multics Fortran compiler was written by David Levin, Paul Smee,
Richard Barnes, and M. Donald MacLaren (completely new and totally independent 
of the Multics PL/I compiler).  The 3rd and final version was a fast compiler
that produced excellent code.
 
1.7.7.  BCPL - Dennis Ritchie and Rudd Canaday ported CTSS BCPL to 
Multics.  Ken Thompson wrote a version of QED in BCPL, and Joe Ossanna 
wrote Multics runoff in BCPL. Robert F. Mabee maintained BCPL after the 
divorce from Bell Labs.

1.7.8.  APL - "A Programming Language," defined by Ken Iverson of IBM.
There were two versions of APL, first one done by Max Smith at CISL,
based on the original IBM APL.  The second one, based on IBM's APLSV,
done in the summer of 1973 by MIT students Bricklin, Moon, 
Lamson, Benedict, and Green, is a fairly complete implementation of APL.  
It even includes the I-beam command that translates text to a function.

1.7.9.  BASIC - The first BASIC we had was true DTSS BASIC running under 
emulation.  Then there was the FAST subsystem, which simulated most of 
the editing features of DTSS as well.  Barry Wolman wrote a BASIC 
compiler which produced native Multics object segments; although quite 
powerful, it didn't get wide usage.

1.7.10.  MACLISP - Multics LISP was one of the first LISP 
implementations on virtual memory.  Multics Version I Lisp was entirely 
in PL/I (including its compiler, which is extremely unusual) by David 
Reed, then an undergraduate at MIT, and was part of the Standard Service 
System libraries.  It was not compatible with any other well-known Lisp.  
There was no Multics software written in it, and it never achieved a 
following or user community.

Version II Lisp was known as "Multics MacLisp" (From "Project MAC",
see above.)  The need for it arose from the MIT Mathlab group's (part
of project MAC, later Laboratory for Computer Science) "Macsyma"
program, which was written in Lisp, hitting against the address space
constraints of the PDP-10 systems on which it was developed.  The
large virtual memory of Multics seemed to indicate the latter as a
logical migration platform, so Multics MacLisp was developed to
support Macsyma.

Multics MacLisp was designed to be compatible with the large, mature,
and heavily used "MACLISP" dialect in use on the PDP-10's throughout
the AI Lab and MAC, and implemented between 1970 and 1973. Reed, then
an undergraduate at MIT in the Multics group, started the project by
modifying Version I Lisp, writing largely in PL/I.  Ultimately,
several of the most performance-critical sections, most notably the
evaluator, were rewritten in a tour-de-force of ALM (Multics Assembler)
by Dave Moon.  Almost all of the implementation was done by Daves Moon
and Reed and Alex Sunguroff; Moon was working in the MIT Undergraduate
Research Opportunities program; Sunguroff, who worked on the I/O
system, was a paid employee.  Daniel Bricklin, later of VisiCalc fame,
worked on the BIGNUM (arbitrary-precision integer arithmetic) package.

The Multics MacLisp Compiler, initially designed and written by Reed
alone, was a full-scale Lisp Compiler producing standard Multics
object segments (which nonetheless had to be run from within the Lisp
subsystem).  Its two phases, semantics and code generation, both
written in Lisp, were derived in conception and strategy from
COMPLR/NCOMPLR, the renonwned and powerful compiler on the PDP-10.
While the code generator was written from scratch, the semantics
phase was ported and adapted from PDP-10 MacLisp.  Reed's code
generator employed a subset NCOMPLR's powerful data-flow techniques.
[An unpublished but widely distributed 1978 paper on these
techniques by Bernard Greenberg is still available from him
(bsg@world.std.com) in ASCII or paper.]  A "LAP" (intrinsic Lisp
assembler program) was written a couple of years later by Moon.

Although Macsyma was ported to Multics, it was not a further impetus
for much Multics Lisp development thereafter.  The cause of Multics
Lisp was taken up by Bernard Greenberg, who had just come to
Honeywell (1974) after having been attracted to Lisp while sharing an
office with Moon at MIT.  Greenberg, who was involved with the
development and continuation of the Multics Supervisor, implemented a
Multics post-mortem crash-analysis program, ifd (interpret_fdump) in
Multics Lisp, which in subsequent years achieved wide distribution
and following in the Multics Community.  While the "official
language" status of PL/I actively and openly discouraged
experimentation with other languages, the interactive, extensible
nature of ifd did much to attract attention to Lisp in the Multics
development and site support communities.

From that time until his departure from Honeywell in 1980, Greenberg
took over maintenance of Multics Lisp, adding features as he needed.
Moon still contributed major features on occasion.

Largely as a consequence of the ifd experience, Greenberg chose
Multics Lisp as the implementation and extension vehicles for Multics
Emacs (1978), which drew attention to Lisp from all over the Multics
community and to Multics from all over the Lisp community.  Multics
Emacs elevated Multics MacLisp to criticality in a highly visible and
significant Multics offering.  Multics Emacs' (see separate section)
highly successful use of Lisp as (inter alia) an extension language
inspired the use of Lisp as such by later generations of Emacs (e.g.,
GNU).

Multics MacLisp featured exploitation of the huge Multics address
space, a copying linearizing garbage-collector, two-word "ITS"
(indirect-to-segment) pointers with nine-bit type fields, fullword,
immediate integers and floats (hence, no need for "number space" and
its concomitant inefficiencies), pure, shareable compiled code (as in
all of Multics), and two stacks besides the regular Multics stack
(GC-marked and non-GC marked).  Because of the large pointers,
immediate numbers, and the resulting lack of need for "special
purpose pages", Multics MacLisp was to a large degree free of the
curse of arcane numeric declarations and fragile number-flow tracing
that plagued the PDP-10 implementation.  System symbols were
lower-case and reading was case-sensitive, consistent with the rest
of Multics but few Lisps.

A powerful, efficient call-out-to-PL/I feature (defpl1) in the
compiler (but not the interpreter) was among the novelties of the
implementation.  (PL/I programs could not call arbitrary Lisp
routines, although the support of PL/I->Lisp callbacks was provided
for the Emacs interrupt system).  defpl1 could actually receive and
create arbitrary-length strings (returns char (*)) from PL/I, in a way
far more natural than PL/I's own.

The Lisp libraries (written in Lisp) featured optional trace and
prettyprint packages and the like, largely taken verbatim from the
PDP-10.  Carl Hoffman, Glenn Burke, and Alan Bawden upgraded these
libraries in 1979 and 1980 to incorporate a large number of language
enhancements (backquote, defstruct, etc.) that had been accepted as
near-standard in the AI community, and were on their way to becoming
part of Common Lisp.

Multics MacLisp was paid for and owned by MIT. It was part of the
"author maintained" library at MIT.  When it became necessary to
distribute it as part of Emacs, which was a Honeywell product, one of
the first parts of Multics to be sold as a separate product,
incidentally, an deal was struck permitting Honeywell to distribute
it. As the close relation of Lisp and Multics Emacs tied the
maintenance of the two together, Greenberg was succeeded as the
maintainer of both, upon his departure to Symbolics in 1980, by
Richard Soley and then Barry Margolin.

[Written by Bernard Greenberg, with contributions from Daves Moon and
Reed and Carl Hoffman.]

1.7.11.  Macsyma - Dave Moon ported Macsyma to Multics in 1974.  Carl 
Hoffman, Alan Bawden, and Glenn Burke updated it around 1980.

1.7.12.  ALGOL 68 - Done by HIS UK.

1.7.13.  Pascal - Oakland used a Pascal compiler from Grenoble 
University.  (Info from Thomas Hacker)

1.7.14.  C - In the late 80s a C compiler was written for Multics.  John 
Wilson worked on porting TeX to Multics using the new Multics C.  (info 
from Stan Zanarotti) <<need more info.  who worked on this, was it a 
product?>>

1.7.15.  Minor languages, e.g. cv_pmf, built with parse_file_

1.7.16.  DTSS provided compilers - There was an ALGOL-60 compiler that ran 
under DTSS emulation.  I got it running about 6-9 months after the DTSS 
BASIC compiler.  There was also a DTSS Fortran compiler that would run, but 
I don't think we installed that, since Multics already had a Fortran 
compiler. [Paul Karger]


1.7.      Command language
Paul Green posted a fine description of the Multics command 
language in April 93.

1.7.1.      emacs
<<more, BSG & others posted remarks 5/29/93>>

1.8.      User programming environment
1.8.1.      Subroutine library
<<more>>

1.8.2.      Structure of a process
<<more>>

1.9.      Graphics
<<more: ARDS/Tektronix graphics, MGS, what were firsts>>

2.      Multics Hardware Features
2.1.      GE-635 and simulators
The Multics machine was a descendant of the GE-635, which was very like 
the IBM 7094.  36-bit word, accumulator, quotient register, index 
registers.  The 635 had more indirect address modes and had 8 XRs 
instead of the 7094's 7.  While the 645 hardware was being designed and 
built, we ran Multics on the 645 simulator, running on the 635.  Project 
MAC had a 635 in the same machine room as the 7094 that CTSS ran on, and 
programmers generated GEIN tapes using the CTSS MRGEDT command, which 
called a special supervisor trap to write a tape in 635 format.  
Operations input the job to the 635 running GECOS III, and ran simulator 
jobs, which usually ended with the simulator detecting a trap and taking 
a dump of virtual core.  The dump was put on an output tape and input to 
CTSS via the disk editor; the programmer then debugged using the 
interactive GEBUG debugger on CTSS.  EPL compilations were done on CTSS 
at first, and then moved to the 635.

2.2.      GE-645 (January 1967)
2.2.1.      System block diagram
<<more>>

2.2.2.      Processor
Cycle time was 1-2 usec for most instructions.
<<more: appending unit, base registers, dseg, page tables>>

2.2.3.      Memory
The GE-645 used 1us cycle memory and had 256KW/box.  Important to note 
that the memory controllers (passive devices) were the center of the 
system.  Memory controllers received requests from active devices like 
CPUs, and had complicated arbitration and priority.  The memory 
controllers also supported a few read-alter-rewrite operations, crucial 
for synchronization.

2.2.4.      Firehose drum
The drum was used on some kind of atomic subs.  It had a capacity of 4 
Million 36-bit words, and could move 1024 words (one page) in 4ms with a 
16ms average latency.  <<more>>

2.2.5.      GIOC
General I/O Controller.  An active device that had its own access to 
memroy.  Had subchannels for disk, tape, terminals.  <<more>>

2.2.6.      Disk subsystems
Initial MIT configuration had 136MB of disk.
<<more: Milking the DS-10s>>

2.2.7.      Calendar clock
The 645 clock was a huge box, 8 foot refrigerator size, containing a 
clock accurate to a microsecond.  It hooked into the system as a 
"passive device," meaning that it looked like a bank of memory.  Memory 
reads from a port with a clock on it returned the time in microseconds 
since 0000 GMT Jan 1, 1901.  (52-bit register) The clock guaranteed that 
no two readings were the same.  It had a real-time alarm register also.  
Inside there was a crystal in an oven, all kinds of ancient electronics.  
The clock diagnostics were very primitive: once we ran them when the 
clock was disconnected, and it passed! "No clock on this port, try to 
read it, shouldn't get any answer, check." Later hardware versions did 
the clock differently, put it inside the memory controller.

The CPUs each had an interval timer, a memory cycle counter that could 
be used for scheduling and CPU accounting.

2.2.8.      Grochow XRAY display
On the 645 we had a special GIOC adapter which looped sending requested 
memory locations to a PDP-8/338 over a 2400 baud phone line.  Jerry 
Grochow wrote a thesis about monitoring Multics operation from this 
display.

2.2.9.      Peripherals
tapes, card reader, punch, CRAM unit. <<more>>

2.1.10.     Terminals
TTY37, IBM 1050, IBM 2741 over phone lines. 
ARDS over 202c6 dataphone: 1200/110 baud. <<more>>

2.3.      Honeywell 6180 (11/72)
2.3.1.      Processor and memory
- Max of 2^15 segments (previously 2^18)
- Max segment size of 2^18 36-bit words (previously 2^16)
- PR pointer registers new (replace ABR pairs)
- "Segment Descriptor" and "Page Table Word" differ,
  as does virtual to physical translation details
- 8 hardware supported rings (previously 64 software rings)
- inward ring calls by hardware (new CALL instruction)
- extended instructions (EIS) new, 9,6 & 4 bit byte & 1 bit ops
  These were multi-byte character string and decimal operations
  (we used to joke that it was as if a 7094 had swallowed a 1401)
- 2K cache in CPU for non-write-shared instructions & data
(info from Richard Wendland & Olin SIbert)
<<more, there were clock changes too>>

2.3.2.      Bulk store
<<more: big slow core bank, replaced drum>>

2.3.3.      DN-355
<<more: replaced GIOC terminal channels with a more standard Honeywell 
datacomm product, connected thru the IOM.  After a while migrated to use 
standard DN-355 software (NPS?) as well.>>

2.3.4.  IOM <<more: Input-output multiplexer.  Replaced GIOC with standard 
Honeywell I/O channel product.>>

2.3.5.      Disk subsystems
<<more: capacity of a DSU-270 (1970) was 10MB, MIT had 15 of them>>

2.4.      Honeywell Series 60 Level 68
The Series 60, Level 68 was just a repackaging of the 6180.  The 
nomenclature "Level 68/M" is incorrect; "68" implies Multics.  Major 
changes included boxes Dick Douglas (a rather short LISD VP) could see 
over the top of and front panels with LEDs instead of little tiny light 
bulbs.  No software-visible changes in the processor (with perhaps the 
exception of some hardware ID configuration register or such).  There 
were visible changes in memory and I/O stuff, as Multics came to support 
the newer modules developed for GCOS (bigger memory, more I/O channels, 
bigger disks, etc.), but I don't believe those ever coincided with a 
change of marketing designator--they just happened in the normal course 
of events.

This line was later called the DPS-68, and the DPS-2, -3, and -4; no 
changes except in marketing designation.

There was a "cut down" 68/80, called the 68/60, that had a one-wire 
change to disable the cache...  actually a switch, 'cause the 
diagnostics wouldn't run with the cache off.  This was a rarity, and I 
think only sold to a few universities.  (Information from Olin Sibert)

2.5.      Honeywell DPS-8/M
These were introduced in late 1982 or early 1983, and continued to be 
sold until 1987 or so (fully two years after Multics was canceled for 
the last time!).

The DPS8/70M, and its later slowed-down cousins, the DPS8/62M and 
DPS8/52M, were the last of the delivered Multics machines.  These were 
based on the GCOS/CP-6 models of the same hardware (which had no suffix 
for GCOS, or suffix C for CP-6, but were otherwise identical).  The 
hardware change was significant: I think only about one-third of the 
boards were identical, another third to half were modified a little, and 
the remainder (addressing and such) were completely different.

The 8/52M and 8/62M just had delays inserted in their clocks this made 
the machine timing less reliable, and it took a LONG time to debug.  The 
8/70M trailed the GCOS model by about two years, the little ones by even 
more.  Hardly any of the slow ones were sold, since they were *more* 
expensive to manufacture than the 8/70M.

There was never a Multics equivalent to the small DPS8 machines 
(DPS8/20, DPS8/44).  A pity, since these were compact and microcoded, 
and actually had enough internal register space and addressing to 
support the Multics memory architecture.  They were bloody expensive to 
build, though, as I recall (like all Honeywell hardware, though, 
curiously, these had been designed by Toshiba), and the low sale price just 
wasn't attractive enough.

The 8/70M came with an 8K (word) cache, later upgraded to 32K (word); 
the latter was definitely optional.  The 8K cache yielded about 1.68 
times the performance of the 6180, the 32K cache about 1.05 times.

There were a few software-visible changes, mostly in configuration 
registers and the like, but one significant user-visible change: 
hexadecimal mantissa floating point for increased exponent range.  And, 
of course, there were new (from GCOS) memories, I/O controllers, and 
peripherals.

UCC got the first production DPS 8s (one of whose doors, containing the 
massive front panels, fell off during installation, leaving the engineer 
holding the thing so it wouldn't pull the connecting cable out by its 
roots).  As such, it certainly had the 8K cache installed, and may have 
upgraded to 32K later.  (Olin Sibert, Deryk Barker)

2.6.      Honeywell ADP, also ORION, eventually DPS88
This machine was never produced, and I do not believe the Multics 
implementation ever saw complete silicon.  It was to have been a Multics 
version of the GCOS DPS88, and would have been about 6 times faster than 
the DPS8/70.  Software work got quite a ways on this, though; that was 
the last project for which I was responsible at Honeywell.  I believe 
this got canceled for good around 1982.  There is some internal evidence 
(in Multics source) that the ADP Multics was resurrected after its Fall 
1981 death before being killed again.  (Olin Sibert)
