Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #212589
| From | Anne & Lynn Wheeler <lynn@garlic.com> |
|---|---|
| Newsgroups | alt.folklore.computers |
| Subject | Re: If Memory Had Been Cheaper |
| Date | 2020-08-08 16:10 -1000 |
| Organization | Wheeler&Wheeler |
| Message-ID | <87r1sgtvqy.fsf@localhost> (permalink) |
| References | <d17fbe8d-9f40-43f3-9924-ca273741cd1fo@googlegroups.com> <2c8a81a9-9273-49a7-b5e5-632b869f93bco@googlegroups.com> |
Terry Kennedy <terry-groups@glaver.org> writes: > The "baby" 370, the 3115 Processor, actually used a bunch (5, IIRC) > 801-ish microprocessors to implement both the 370 instruction set and > the I/O control- lers. IBM also offered plug-in 370-ish processor > boards for the IBM PC and AT - the XT/370 and the AT/370. These were > done with a custom Motorola 68K for the CPU core and an Intel 8087 for > floating point. These boards were "problem state" (IBM's term for user > application programs) compatible with the 370 instruction set but not > for privileged execution (supervisor state / operating system). They > needed a rather heavily modified version of VM/SP to run. Boeblingen got their hands slapped for 115/125. They had 9-position memory bus for (up to) nine microprocessors. For the 115, all the microprocessors were the same. For the 125, the microprocessor running 370 microcodee was 50% faster. As undergraduate, I had done a lot of work on CP67 to reduce its fixed real memory requirements to improve it running on 256kbyte 360/67 ... including making parts of the kernel pageable (while lot of other stuff I did as undergraduate shipped in standard CP67, pageable kernel pieces didn't ship until VM370). In the morph from CP67->VM370, they simplified and/or dropped a lot of stuff (including all my dynamic adaptive resource management and scheduling). However, they still managed to greatly bloat the vm370 fixed real memory (even with pieces of the kernel pageable). It was so bloated that it wasn't even announced for (370/125) 256kbyte memory. I get con'ed into getting vm370 running on 370/125 for a Scandinavian ship company (cutting back on the vm370 real memory bloat). I then get con'ed into design of 5-way 370/125 multiprocessor ... up to five of the 125 microprocessors (which never announced/shipped) ... I define a microcoded queued interface for dispatching and disk I/O ... VM kernel puts things on the dispatching list ... but microprocessors pull things off the dispatching list for execution ... when done ... they place request block on queue for kernel execution. Do something similar for disk i/o requests (disk controller, can pull things off for optimal disk servicing throughput ... not FIFO). About the same time I do the 5-way 370/125 effort, Endicott con's me into doing a lot of work for 138/148 ECPS microcode. Told that 370 instructions drop into microcode on about a byte-for-byte basis with ten times speed up. There is 6kbytes of available microcode storage and need to identify the 6kbytes of highest kernel execution pathlengths. Old archive post that identified the 6kbytes of highest executed kernel pathlengths accounted for 79.55% of kernel exeuction time http://www.garlic.com/~lynn/94.html#21 I also established that all the 138/148 ECPS changes could also be done for the 125 5-way multiproceessor. However, then Endicott complained that the 125 5-way multiprocessor would overlap the throughput of the 148. In the escalation meetings I had to do the arguments for both sides of the table ... however corporate decided that the 125 5-way multiprocessor wouldn't get announced. Note that first half of the 70s, internally there was the Future System project ... that was completely different than 370 and was going to completely replace 370s original motivation was to signficantly raise barrier for clone controllers (370 efforts were being killed off and the lack of new 370 stuff during the period is credited with giving clone 370 processor makers market foothold). When FS imploded, there was a made rush to get stuff back into 370 product pipelines ... and quick & dirty 3033 and 3081 efforts were kicked off in parallel some more details http://www.jfsowa.com/computer/memo125.htm Head of POK managed to convince corporate to kill off the vm370 product, shutdown the vm370 group (burlington/mass), and transfer all the people to POK to work on MVS/XA (or otherwise MVS/XA wouldn't be able to ship on time). Eventually Endicott managed to save the vm370 product mission, but had to reconstitute a VM370 development group from scratch. Endicott also tried to have VM370 integrated into every 138/148 shipped (something like current LPAR) ... but they weren't able to get that through corporate. trivia: POK wasn't going to tell the VM370 group until the last minute to minimize the number of people that manage to escape. The information leaked and there was a witch hunt for who leaked the information (fortunately for me, nobody leaked who it was). This was in the early days of DEC VMS and one of the jokes is that the head of (IBM) POK was one of the largest contributors to VMS. By the 80s, there was significant more bloat for both VM370 and CMS. They send me an early XT/370 to play with and do a lot of benchmarks showing page thrashing with its 384kbyte 370 memory. Endicott blames me for a six month slip in announce and ship to customers while they upgrade 370 memory from 384kbyte to 512kbyte. The XT/370 processor doesn't do any device I/O ... everything is interprocessor communication with application running on 8088 ... doing I/O to the PC/XT devices. The page thrashing and throughput was aggrevated by all CP paging & CMS file I/O was done to the XT hard disk at 100ms per record. I also contributed a page replacement algorithm that was more effective ... especially in constrained memory environment. -- virtualization experience starting Jan1968, online at home since Mar1970
Back to alt.folklore.computers | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
If Memory Had Been Cheaper Quadibloc <jsavard@ecn.ab.ca> - 2020-08-06 14:24 -0700
Re: If Memory Had Been Cheaper Terry Kennedy <terry-groups@glaver.org> - 2020-08-06 16:59 -0700
Re: If Memory Had Been Cheaper Quadibloc <jsavard@ecn.ab.ca> - 2020-08-06 17:22 -0700
Re: If Memory Had Been Cheaper Anne & Lynn Wheeler <lynn@garlic.com> - 2020-08-08 16:10 -1000
Re: If Memory Had Been Cheaper Terry Kennedy <terry-groups@glaver.org> - 2020-08-08 21:07 -0700
Re: If Memory Had Been Cheaper Peter Flass <peter_flass@yahoo.com> - 2020-08-09 10:07 -0700
Re: If Memory Had Been Cheaper Anne & Lynn Wheeler <lynn@garlic.com> - 2020-08-09 11:04 -1000
Re: If Memory Had Been Cheaper Anne & Lynn Wheeler <lynn@garlic.com> - 2020-08-09 12:03 -1000
Re: If Memory Had Been Cheaper Peter Flass <peter_flass@yahoo.com> - 2020-08-09 15:30 -0700
Re: If Memory Had Been Cheaper J. Clarke <jclarke.873638@gmail.com> - 2020-08-07 10:24 -0400
Re: If Memory Had Been Cheaper timcaffrey420@gmail.com - 2020-08-07 11:26 -0700
Re: If Memory Had Been Cheaper timcaffrey420@gmail.com - 2020-08-07 11:33 -0700
Re: If Memory Had Been Cheaper Terry Kennedy <terry-groups@glaver.org> - 2020-08-07 13:30 -0700
Re: If Memory Had Been Cheaper Peter Flass <peter_flass@yahoo.com> - 2020-08-07 11:39 -0700
Re: If Memory Had Been Cheaper drb@ihatespam.msu.edu (Dennis Boone) - 2020-08-07 14:11 -0500
Re: If Memory Had Been Cheaper Quadibloc <jsavard@ecn.ab.ca> - 2020-08-07 12:35 -0700
Re: If Memory Had Been Cheaper Quadibloc <jsavard@ecn.ab.ca> - 2020-08-07 12:37 -0700
Re: If Memory Had Been Cheaper J. Clarke <jclarke.873638@gmail.com> - 2020-08-08 13:23 -0400
Re: If Memory Had Been Cheaper Anne & Lynn Wheeler <lynn@garlic.com> - 2020-08-08 16:29 -1000
Re: If Memory Had Been Cheaper J. Clarke <jclarke.873638@gmail.com> - 2020-08-08 13:21 -0400
Re: If Memory Had Been Cheaper Peter Flass <peter_flass@yahoo.com> - 2020-08-07 11:31 -0700
Re: If Memory Had Been Cheaper Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-08-07 10:05 -0600
Re: If Memory Had Been Cheaper Quadibloc <jsavard@ecn.ab.ca> - 2020-08-08 14:23 -0700
Re: If Memory Had Been Cheaper undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2020-08-15 11:42 -0700
Re: If Memory Had Been Cheaper Quadibloc <jsavard@ecn.ab.ca> - 2020-08-15 21:48 -0700
Re: If Memory Had Been Cheaper undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-07 12:36 -0700
Re: If Memory Had Been Cheaper J. Clarke <jclarke.873638@gmail.com> - 2021-07-07 17:03 -0400
Re: If Memory Had Been Cheaper Robin Vowels <robin.vowels@gmail.com> - 2021-07-07 23:13 -0700
Re: If Memory Had Been Cheaper Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-07-08 09:51 -0600
Re: If Memory Had Been Cheaper char <char@code.ord> - 2021-07-08 17:56 -0500
Re: If Memory Had Been Cheaper Quadibloc <jsavard@ecn.ab.ca> - 2021-07-08 09:31 -0700
Re: If Memory Had Been Cheaper Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-07-08 18:14 +0000
Re: If Memory Had Been Cheaper char <char@code.ord> - 2021-07-08 18:00 -0500
Re: If Memory Had Been Cheaper undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-13 15:21 -0700
Re: If Memory Had Been Cheaper undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-16 11:13 -0700
Re: If Memory Had Been Cheaper J. Clarke <jclarke.873638@gmail.com> - 2021-07-16 17:20 -0400
Re: If Memory Had Been Cheaper undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-20 12:08 -0700
Re: If Memory Had Been Cheaper Vir Campestris <vir.campestris@invalid.invalid> - 2021-07-20 21:30 +0100
Re: If Memory Had Been Cheaper Quadibloc <jsavard@ecn.ab.ca> - 2021-07-22 04:09 -0700
Re: If Memory Had Been Cheaper Thomas Koenig <tkoenig@netcologne.de> - 2021-07-22 13:51 +0000
Re: If Memory Had Been Cheaper Quadibloc <jsavard@ecn.ab.ca> - 2021-07-22 14:50 -0700
Re: If Memory Had Been Cheaper Ahem A Rivet's Shot <steveo@eircom.net> - 2021-07-07 22:20 +0100
Re: If Memory Had Been Cheaper Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-07-07 18:52 -0600
Re: If Memory Had Been Cheaper undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2021-07-13 15:15 -0700
Re: If Memory Had Been Cheaper Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-07-14 00:02 +0000
Re: If Memory Had Been Cheaper J. Clarke <jclarke.873638@gmail.com> - 2021-07-13 21:30 -0400
Re: If Memory Had Been Cheaper Vir Campestris <vir.campestris@invalid.invalid> - 2021-07-11 21:31 +0100
Re: If Memory Had Been Cheaper JimP <chucktheouch@gmail.com> - 2020-08-16 11:15 -0500
Re: If Memory Had Been Cheaper hancock4@bbs.cpcn.com - 2020-08-17 12:36 -0700
Re: If Memory Had Been Cheaper Quadibloc <jsavard@ecn.ab.ca> - 2020-08-18 02:04 -0700
Re: If Memory Had Been Cheaper JimP <chucktheouch@gmail.com> - 2020-08-19 07:53 -0500
Re: If Memory Had Been Cheaper Robert Swindells <rjs@fdy2.co.uk> - 2020-08-19 14:15 +0000
Re: If Memory Had Been Cheaper JimP <chucktheouch@gmail.com> - 2020-08-19 10:51 -0500
Re: If Memory Had Been Cheaper undefined Hancock-4 <hancock4@bbs.cpcn.com> - 2020-08-15 11:39 -0700
Re: If Memory Had Been Cheaper Quadibloc <jsavard@ecn.ab.ca> - 2020-08-15 21:54 -0700
Re: If Memory Had Been Cheaper gah4 <gah4@u.washington.edu> - 2021-07-27 22:58 -0700
Re: If Memory Had Been Cheaper David Lesher <wb8foz@panix.com> - 2020-08-16 21:44 +0000
csiph-web