The CPUs run at about one MIP; instructions were 36 bit wide, with an 18 bit operand, allowing a segment size of 256 thousand words. Segment numbers are 15 bits, allowing 32 thousand segments of 256 thousand words each, or about a theoretical 8 gigabytes of address space per process; Multics table sizes and backing store sizes set a smaller limit on the size. Two thirty-six bit accumulators, A and Q. Eight eighteen bit index registers, X0-X7. Eight pointer/address registers, each containing a fifteen bit segment number, eighteen bit address and six bit bit number.
An elaborate indirect addressing scheme, allowing chained indirection, tally decrements and address increments, register indexing and segment crossing. (An interesting side note: the no-operation instruction includes an operand address and address preparation is performed, which includes walking the indirection chain; this means that the no-operation instruction can alter memory, page fault, and incur access violation faults).
The CPU does thirty six and seventy-two bit integer and floating point arithmetic, ten digit decimal arithmetic, string move and compare, and decimal number formatting (as in COBOL and PL/I “PIC”).
The CPU operates in two modes, absolute mode with memory access to the low 256K of memory and privileged instructions and append mode, with segmented memory access. Physical memory addresses are twenty four bits, allowing sixteen megawords of physical memory.

On Sept. 21, [2017], I stumbled across a document:
"EMULATING A HONEYWELL 6180 COMPUTER SYSTEM"
A report prepared by Mitre Corporation for the Rome Air Development Center, dated June, 1974.
Here was a document containing answers to everything we had spent years struggling with.
Fortunately for our mental health, that was not the case.
The report is a proposal discussing the feasibility and scope of such a project.
It contains a 39-page summary of the 358 pages of AL39, including the nine page Append Cycle flowchart compressed down to two pages, and interestingly, fixing the ring write bracket register number typo.
It then spends six pages discussing design strategies...
They then describe a “benchmark” emulaton used to judge the suitability of various host computers...
They then evaluate the feasibility of implementing the benchmark on a Burroughs D-machine, a Nanodata QM-1, and a Burroughs B1700.
They then estimate emulation speeds on the three machines.
They never actually write any code or estimate the scope of writing an complete emulation.

Current status: Release 1.0, bugfix release 1.0.1 imminent
87,546 lines of C
Decimal math library: 20,235
Event library: 2,145
Total: 105,781

As a comparison, simh Alpha runs about 7K lines of C, simh PDP-10 about 13K and simh VAX
about 63K.

There is an outstanding bug in the emulator -- the GTSS GCOS simulator crashes. The crash occurs in code taken from a GCOS library that we do not have the source for and identifying the issue remains elusive.
Examination of the Multics source leads to the observation that most of Multics is written in PL/I, and that the Multcs PL/I compiler generates a limited set of memory addressing code sequences. This implies that only a few paths are taken through the memory addressing portions of the emulator and that those paths are well exercised and debugged.
The GCOS code was written by a different team of engineers, who in all probability used different memory addressing patterns, and that the GCOS code takes different, un-debugged code paths through the emulator.