Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > alt.folklore.computers > #212589

Re: If Memory Had Been Cheaper

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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