Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lynn Wheeler <lynn@garlic.com>
Newsgroups: comp.arch
Subject: Re: backward architecture, The Design of Design
Date: Wed, 08 May 2024 15:43:52 -1000
Organization: Wheeler&Wheeler
Lines: 51
Message-ID: <87frurn4iv.fsf@localhost>
References: <v03uh5$gbd5$1@dont-email.me> <20240507115433.000049ce@yahoo.com>
	<v1fim7$3t28r$1@dont-email.me> <20240508141804.00005d47@yahoo.com>
	<v1gncp$1en9$1@gal.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Thu, 09 May 2024 03:43:58 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="c5b89ced7521d2428a176623cef093ad";
	logging-data="315667"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/DaWLFyYa6ZUs439FlSxzaTU8latspMco="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:gYlKR3BI2pysaBI7IGq4SMeB3tE=
	sha1:YORjus4VO2ohlDdCKZ2yhfrUZ7Y=
Bytes: 3855

John Levine <johnl@taugh.com> writes:
> implementations of each one. So when they went to S/370, there was the
> 370/115, /125, /135, /138, /145, /148, /158, and /168 which were
> upward and downward compatible as were the 303x and 434x series. The
> /155 and /165 were originally missing the paging hardware but later
> could be field upgraded.

shortly after joining IBM I get con'ed into helping 370/195 to add
multi-threading; 195 pipeline didn't have branch prediction, speculative
execution, etc ... so conditional branches drained the pipeline ... and
most codes only ran at half rate. Multi-thread would simulate two
processor operation ... and two i-streams running at half rate might
keep aggregate 195 throughput much higher (modulo the OS360 MVT
multiprocessor support only having 1.2-1.5 throughput of single
processor).

little over decade ago I was asked to track down decision to add virtual
memory to all 370s and found staff to executive making the
decision. Basically OS/360 MVT storage management was so bad, the
execution regions had to be specified four times larger than used, as a
result a 1mbyte 370/165 normally would only run four regions
concurrently, insufficient to keep system busy and justified. Mapping
MVT to a 16mbye virtual address space (aka VS2/SVS) would allow
increasing number of concurrently running regions by factor of four
times (with little or no paging), keeping 165 systems busy
.... overlapping execution with disk I/O.

I had gotten into something of a dustup with VS2/SVS, claiming their
page replacement algorithm was making poor choices ... they eventually
fell back to since they were expecting nearly negligible paging rates,
it wouldn't make any difference.

Along the way, 370/165 engineers said that if they had to retrofit the
full 370 virtual memory architecture ... it would slip the announcement
date by six months ... so decision was made to drop features ... and all
the other systems had to retrench to the 165 subset ... and any software
dependent on the dropped features had to be reworked. For VM/370, they
were planning on using R/O shared segment protection (one of the
features dropped for 370/165) for sharing CMS pages ... and so had to
substitute a real kludge. Also the 370/195 multi-threading was canceled
.... since it was deamed to difficult to upgrade 195 for virtual memory.

Amdahl had won the battle to make ACS, 360 compatible ... folklore is
that executives then killed ACS/360 because it would advance the
state-of-the-art too fast and IBM could loose control of the market
(Amdahl leaves IBM shortly later)
https://people.computing.clemson.edu/~mark/acs_end.html
.... above also has multi-threading reference.

-- 
virtualization experience starting Jan1968, online at home since Mar1970