🚀 go-pugleaf

archive-name: multics/features
URL: //www.multicians.org/features.html

Please post updates to alt.os.multics or mail to <thvv@multicians.org>
====================================================================




1. Multics Software Features

The goals and Notable Features of Multics are described in Multics
  General Information:
* Segmented memory
* Virtual memory
* High-level language implementation
* Shared memory multiprocessor
* Multi-language support
* Relational database
* Security
* On-line reconfiguration
* Software engineering

Additional features are described below.


Honeywell 6180 Control Panel




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. (Jerry Saltzer)

1.2. Virtual memory management

Paul Green posted a description in May 93. { Multics Virtual Memory}

1.2.1 Multics Disk DIM

The work done at ACTC to optimize disk performance resulted in an
  Adaptively Optimizing Disk DIM, in the MR11 time frame. This was the
  first major use of floating point within the hardcore.

This disk DIM provided a tunable, load-sensitive, optimization algorithm
  on a per-I/O-type, per-drive basis, and provided a site the ability to
  use a system-wide tunable disk-queue resource pool.

Optimization priority set a high (and exclusive) priority for VTOC I/O
  and Page Reads. Initial priority of Page Writes excluded them from
  competition with Page Reads, unless they were on-cylinder. This
  addressed the need to expdite blocking I/O and defer non-blocking I/O.

As queued I/Os built up for any I/O type, on a per-drive basis, the
  optimizer increased the priority accorded to the nearest-seek-first
  algorithm, for that I/O type on that drive, and the I/O became more
  competitive. This recognized the significance of queue resource loading
  converting a non-blocking I/O into a blocking I/O.

As a fallback, if any I/O on any drive was not serviced within a tunable
  time period, default of 5 seconds, the optimization method changed to
  disk combing until the stagnation criteria was resolved.

Optimization validation was done on a three processor system, with 5
  MSU501 disks, and achieved sustained disk loading of 100% on 4 drives
  and 98% on the fifth for over 2 hours. During this time we could
  actually log in and do work, but it was really slow. The same load on a
  stock system caused page thrashing to the extent that a reboot was
  required to get control back. The system was so thoroughly locked up
  that the Initializer never got the instruction and data page in memory
  at the same time, and over the period of 1 hour was unable to kill the
  thrashing test job(s).

An interesting side-note. The thrashing test generation software was done
  using Multics FORTRAN Very Large Array code, since it provided easy
  access to large amounts of memory. (Tom Oke)

1.3. Dynamic linking

Multics needs no loader. Write a procedure, say <span
  class=cmd>joe</span>, and compile: suppose the resulting binary refers
  to an external subroutine called <span class=cmd>fred</span>. You can
  run <span class=cmd>joe</span> by just typing its name. The command
  processor launches it by just finding the segment <span
  class=cmd>joe</span>, adding it to the user process's address space,
  and jumping to the entrypoint. <span class=cmd>fred</span> may not even
  exist, and if <span class=cmd>joe</span> never calls it, no problem. If
  <span class=cmd>joe</span> does call <span class=cmd>fred</span>, a
  linkage fault occurs. The system linkage fault handler searches for a
  file named <span class=cmd>fred</span>, adds it to the address space
  and fixes the linkage to go fast next time (by changing a Fault Tag 2
  indirect word to an ITS pair), and continues the faulting instruction.
  If <span class=cmd>fred</span>'s not found, the user gets a fault
  message, and can quickly write a <span class=cmd>fred</span>, compile
  it, and then continue execution of <span class=cmd>joe</span>, which
  will then find <span class=cmd>fred</span>. (more: binder, run units,
  resolve_linkage_error 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 Bob
  Mullen's virtual deadline scheduler which supports specification of
  desired realtime response (N milliseconds in M) for system processes
  such as printer daemons, and supports "work classes" that can 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 are mapped into work classes via the Master
  Group Table (MGT), managed by the system administrators.

The non-realtime classes are managed according to an exponential
  discipline that favors interactive usage. The scheduler translates the
  non-realtime class controls into virtual deadlines, and schedules these
  with the realtime class deadlines, satisfying "hard" deadlines first
  and virtual ones last.

1.5. Instrumentation

Multics has 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 hardcore subsystems have metering built in,
  running all the time; the commands just display the internal counters.
  The standard procedure for installing a new system release included
  running a 60-minute performance benchmark.

1.6. Accounting & administration

Multics provides a set of applications for printing monthly usage reports
  and bills for timesharing users. CPU usage is 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 have disk 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 cause it to compile
  zero lines per minute. A lot of features of PL/I not needed for system
  programming, such as I/O statements and decimal data, were left out of
  EPL. (See MSPM BB.2.01 EPL Subset for System Programming for a
  description.)

1.7.2. EPLBSA

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

1.7.3. PL/I

The PL/I language was defined by IBM. Few other languages with pointers
  were 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.)

The "version 1" PL/I compiler was written in EPL at GE/CISL and then used
  to compile itself. It provided great improvements in speed and
  diagnostics over EPL. PL/I compiled directly to Multics object
  segments.

The "version 2" compiler, also from CISL, was robust, efficient, and a
  clean implementation of the language. It made much better use of the
  stack segment.

Almost all of the operating system was written in PL/I.

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. Replaced EPLBSA. A clean, spare assembler.
  Used for programs that needed ultimate efficiency or that issued
  privileged instructions, and to define and initialize data segments.

Nate 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 PL/I 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.6.1 Hexadecimal Floating Point

When hexadecimal floating point was added to the Multics CPU, ACTC
  developed the math library support for this feature. This included a
  rewrite of the Multics runtime library subroutine <span
  class=cmd>any_to_any_</span>, the introduction of a number of
  additional data types which had very large exponent ranges, and
  redeveloped trig functions with higher accuracy and speed. (Tom Oke)

1.7.6.2 Very Large Arrays

Many users had indicated that the limit of 255K word segments (< 1MByte)
  was a significant limit in the size of arrays that they could use in
  FORTRAN. ACTC was commissioned to provide Large and Very Large Array
  support.

Large Arrays provided up to a full segment per array, packing arrays into
  segments as appropriate. Normal addressing was done for each array,
  which retained the full normal execution efficiency of the FORTRAN
  Compiler.

Very Large Array support provided natural addressing of arrays of up to
  16MWords each. This addressing was done with pointer arithmetic and
  some extensions to the hardcore to support 256 page segments.

The Multics FORTRAN compiler had a good flow optimizer which produced
  very efficient code. The Very Large Array work included optimization of
  the pointer arithmetic.

Timing results indicated that a classical matrix multiply was roughly 5%
  slower unoptimized, and 25% slower optimized than the normal short
  array code. This was considered to be very good for a project which had
  a design envelope of VLA code no more than 2* as slow non-VLA code.
  (Tom Oke)

1.7.7. BCPL

Bootstrap Combined Programming Language. A language defined by Martin
  Richards of Cambridge, for bootstrapping CPL. Richards visited MIT and
  brought the language with him.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 Multics APL, the 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 Dan Bricklin, Dave Moon, Richard
  Lamson, Gordon Benedict, and Paul 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 Dave 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. Dan 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 of
  NCOMPLR's powerful data-flow techniques. [A 1977 paper on The Multics
  MacLisp Compiler by Bernard Greenberg is available at this web site.] 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 at CISL.

[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

HIS UK commissioned this to a group of people at Bath University. Martyn
  Thomas, of X-Open fame, was the team leader. Geoff Reece was another
  team member. [info from Warren Johnson] John Baker worked on the
  project, seconded from Bristol University to SWURCC who had the
  contract to do the Multics Algol68 implementation. [info from Kit
  Powell]

1.7.13. Pascal

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

James Gosling wrote a Pascal at Calgary for Multics, but Bull chose to
  support the Grenoble one instead. The Gosling compiler became "a cult
  classic." (Info from James Gosling.)

1.7.14. C

The Multics C compiler was developed at ACTC from the Portable C compiler
  by a group led by Tom Oke, and including Doug Robinson, Alfred Hussein,
  and Doug Howe. Most of the difficulties which ensued in the development
  surrounded getting an addressing model for the "cookies" which matched
  the Multics hardware addressing. The Multics register model and the PCC
  register model collided a lot.

The compiler was not particularly efficient, due to the nature of PCC,
  and the lack of optimziation, but it provided utility to those who
  succeeded in getting their applications up and running. (Tom Oke)

John Wilson worked on porting TeX to Multics using the new Multics C.
  (Stan Zanarotti) (need more info. who worked on this, was it a
  product?)

A C compiler for Multics was proposed at Waterloo. It was to be derived
  from the GCOS 8 compiler. Preliminary investigations were done but no
  formal bid was submitted, and the project got lost in internal
  Honeywell politics. (David Collier-Brown, Alan Bowler)

1.7.15. Minor languages

Many Multics facilities have "little languages," defined with the
  parse_file_ subroutine, that read an ASCII file and produce a simple
  binary sturcture. The administration package contains five or six of
  these, for example cv_pmf.

1.7.16. DTSS provided languages

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.8. Command language

Multics originated the concept that what you type at command level should
  be the name of a program that you want to call; a whole flock of ideas
  such as search rules, working directories, the shell, and redirectable
  I/O accompanied that innovation, and again this set of innovations is
  found in virtually every operating system that followed. (In CTSS and
  earlier systems, all commands were owned by the system, which had to be
  recompiled to add one; you ran your own programs by executing a system
  command that loaded and ran them.)(Jerry Saltzer)

See the command language section of the Glossary for more.

1.8.1. emacs

{See "Multics Emacs: The History, Design and Implementation"}

1.9. User programming environment



1.9.1. Subroutine library

Unlike many other systems, Multics makes available a large library of
  utility routines used to construct the standard commands. These
  routines are shared by all programs that call them by the dynamic
  linking mechanism.

1.9.2. Structure of a process

(more)

1.10. Graphics

The Multics Graphics System (MGS) was heavily influenced by the design of
  the ESL Display station attached to CTSS at Project MAC in the mid-60s.
  This device was a display-file driven computer with DMA access to the
  7094's memory. MGS graphics programs were device-independent and object
  -oriented, and worked on both dynamic graphic devices and on the
  relatively low-cost and low-speed storage tube devices such as the CGI
  ARDS and the Tektronix 4103.

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. Same 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)

See Glaser, E. L., J. F. Couleur, and G. A. Oliver, "System design of a
  computer for time-sharing applications", for a general discussion of
  the GE-645.

2.2.1. System block diagram

Here is the block diagram of a small Multics GE-645 system, similar to
  the initial system installed at MIT.


2.2.2. Processor

Cycle time was 1-2 usec for most instructions. The basic speed of the 645
  was about 435 KIPS. (more: appending unit, base registers, dseg, page
  tables)

2.2.3. Memory

The GE-645 used 1us cycle memory and had 256KW/box. (Richard Shetron
  reports that the RADC 645 had 500ns core memory. Maybe all 645s did,
  have to check this out.) 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

Also called the Librafile. A large, fixed-head disk used first as simply
  the highest-speed secondary storage device, then as a storage device
  targeted for user temporary segments such as stacks, and finally as the
  first paging device. "Firehose" was a reference to its high rate of
  data delivery. 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
  memory. Had subchannels for disk, tape, terminals. (more)

2.2.6. Disk subsystems

Initial MIT configuration had 136MB of disk.

I don't remember the model off the top of my head, but the RADC machine
  had 200MB/spindle drives (7 of them in early 79). (Richard Shetron)

(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.2.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


* CPU speed about 1 MIPS
* 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

(TVV, Richard Wendland & Olin Sibert)

The semiconductor RAM was 750ns on the early models in the late 70's. I
  think the early boxes where 4MW/box and later this was upped to
  16MW/box. RADC upgraded to a 6180 CPU but kept the 500ns core memory.
  Simple integer instructions took 500ns, floating point around 2-4ms.
  (Richard Shetron)

Clock was changed from a separate active device (used up a port) to being
  contained in the memory controller. A lot of cleverness had to be done
  to make programs portable between the 645 and 6180.

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)