Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Lynn Wheeler Newsgroups: comp.arch Subject: Re: mainframe vs mini, old and slow base and bounds, Why I've Dropped In Date: Sun, 22 Jun 2025 12:15:41 -1000 Organization: Wheeler&Wheeler Lines: 56 Message-ID: <87frfr4e42.fsf@localhost> References: <0c857b8347f07f3a0ca61c403d0a8711@www.novabbs.com> <063443d12af75982698da4630c30360c@www.novabbs.com> <1036fcc$mqkh$1@paganini.bofh.team> <1036ru4$n39$1@gal.iecc.com> <1039ooq$10nvk$1@paganini.bofh.team> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Mon, 23 Jun 2025 00:15:44 +0200 (CEST) Injection-Info: dont-email.me; posting-host="b5934a9d449940f570176126c509c428"; logging-data="834473"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19BFWUpreG7OgfSKlsRM2/G+7qDNwiG2uo=" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:b3KWp4spwqnuPe9H0MbcbEZDm/g= sha1:xWVrYvFerWUy4fForNG3XGoMdw8= Xref: csiph.com comp.arch:112309 antispam@fricas.org (Waldek Hebisch) writes: > Even more fuzzy were models keeping microcode in core: IIUC in principle > determined user could take over microcode store and run user programs > directly on the hardware. That way machine would be more like a > mini with rather inconvenient instruction set, but much faster than > using 360 instruction set. Boeblingon (germany) 115/125 was even more divergent. They had nine position memory bus for microprocessors. For 115, all the microprocessors were the same, one running 370 microcode (avg ten native instructions/370 instruction, at about 370 80KIPS) and others running (I/O integrated) "controller" microcode. The 125 was the same but the microprocessor running 370 microcode was 50% faster .... getting about 370 120KIPS (1.2MIPS native microprocessor). I get con'ed into doing design/implementation where could have up to five (125) 370 microprocessors in a SMP configuration. At the same time Endicott asks me to help with doing ECPS for the 138&148 370 machines. Identify 6kbytes of highest executed vm370 (virtual machine) kernel pathlengths for moving into native microcode (at 10:1 performance increase). Archived (a.f.c.) post with initial analysis (6kbytes accounted for 79.55% of kernel execution) https://www.garlic.com/~lynn/94.html#21 I was also going to include superset of the 138/148 ECPS work in the 5-CPU 370/125 SMP (in part because there was more available microcode space). Then Endicott complains that the 5-CPU 370/125 would overlap 370/148 throughput at better price/performance and in the corporate escalation, I had to argue both sides, and Endicott wins (and the 5-CPU 370/145 SMP work was canceled). This was all in the mid-70s aftermath of Future System implosion and the mad rush to get stuff back into the 370 product pipelines ... at the high-end kicking off 3033&3081 efforts in parallel. Head of (mainframe high-end) POK also manages to convince corporate to kill the vm370 product, shutdown the development group and transfer all the people to POK for MVS/XA (Endicott eventually manages to save the VM370 product mission for the mid-range, but had to recreate a development group from scratch). https://en.wikipedia.org/wiki/IBM_Future_Systems_project https://people.computing.clemson.edu/~mark/fs.html http://www.jfsowa.com/computer/memo125.htm The 370 extensions for high-end (370/XA) had no provisions for supporting virtual machine operation. Some of the old VM370 group do a primitive virtual machine operation and the (3081) "SIE" instruction (for moving into & out of virtual machine mode) in support of MVS/XA development ... never intended for customer release or production. Further aggrevating the situation was 3081 lacked the microcode space for the "SIE" instruction and microcode had to be swapped-in when entering and exiting virtual machine mode. -- virtualization experience starting Jan1968, online at home since Mar1970