Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Lynn Wheeler 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: <20240507115433.000049ce@yahoo.com> <20240508141804.00005d47@yahoo.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 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