uhler Minutes of the Jupiter brainstorming meeting 19830320

This document summarizes the minutes of a brainstorming meeting held on March 3, 1983, to reconsider design decisions for the Jupiter II CPU. Key topics and concerns discussed included:

1. Multiprocessing Configurations:

   • Challenge: Jupiter's MBOX and memory are tightly coupled, making Symmetric Multiprocessing (SMP) difficult compared to KL10 systems.
   • Requirements for SMP: Design of multi-port memory, cache consistency hardware, synchronous clocking, and inter-processor communication.
   • Physical Layout: Multi-ported memory would likely require a separate cabinet between processor cabinets.
   • Concerns: How to connect I/O, the current 25-bit memory address (suggested 27 bits for 128 Mwords), and the potential for SMP to slow down single-processor performance.
   • Priority: TOPS-20 is committed to LCS/CFS, making SMP a secondary priority, though still considered useful if it can be contained within a single cabinet. A low-overhead inter-processor communication bus was requested for loosely coupled systems.

2. External Array Processors:

   • Problem: Jupiter II's tightly coupled MBOX and memory lack external memory ports, unlike KL10 systems.
   • Proposed Solution: Connecting via the I/O bus to the MBOX.
   • Concern: The maximum throughput of one word every 336 ns (at 28ns clock speed) via the I/O bus might be insufficient.

3. COBOL Performance:

   • Problem: The current EXTEND instructions are unlikely to achieve the desired four-times KL10 performance without significant special-purpose hardware.
   • Proposed Solutions: Convert EXTEND-using code to other instructions, define new EXTEND instructions, implement hardware for simple byte-move operations (like MOVSLJ), and store common translate tables in RAM to avoid memory references. An action item was to determine the fastest MOVSLJ-equivalent implementation.

4. Performance Measurement Hooks:

   • Goal: Add features to Jupiter II for easier extraction of performance information.
   • Suggestions: Bring relevant signals to the backplane/spare module slot for meter boards, implement low-overhead hardware for opcode histograms and address/PC traces (with MBOX buffering), and count micro page faults.

5. Translation Buffer (TB) Organization:

   • Context: Addressing problems with the KL10 TB. Jupiter II's current TB is 2K, 1-way associative, 1-word block size in the MBOX.
   • Proposed Enhancements: Various K-way associative configurations, separate user and executive tables (1K, 2-way favored), including a user process context number to avoid TB flushes on context switches, and a single physical page sweep function to replace full TB flushes when physical page states change.
   • Need: Real address traces and a simulator are required to make rational decisions, with preliminary data to be provided internally.

6. I/O Strategy:

   • Concerns: I/O bandwidth for a machine 4-5 times a KL10, reliance on corporate front-ends, and the performance impact of front-ends.
   • Proposed Solutions:
     • Build a UNIBUS adapter (with bus master capability) to reduce dependency on corporate front-ends and leverage UNIBUS peripherals.
     • Build an SI adapter to connect directly to new corporate smart disks, offering an alternative to CI/HSC.
     • Add a small -10 instruction set processor between the MBOX and I/O to handle I/O and offload the main CPU (potentially reducing monitor overhead by up to 20%).
   • Security: Consensus that encryption is needed on the NI, at least to the level available on the UNIBUS.