Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Anne & Lynn Wheeler Newsgroups: alt.folklore.computers,comp.sys.raspberry-pi Subject: Re: S/360 stacks, was self-modifying code, Is it a lost cause? Date: Tue, 05 Jul 2016 07:54:51 -0700 Organization: Wheeler&Wheeler Lines: 102 Message-ID: <87bn2cp22s.fsf@garlic.com> References: <1107158795.489361340.954697.peter_flass-yahoo.com@news.eternal-september.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="6a701f7a2f120c3c3ec794af16136f6c"; logging-data="16552"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18jnT76qETgOOAY2mTYNrPv2FMJvYqaKXI=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.94 (gnu/linux) Cancel-Lock: sha1:e0fnTZCg5KJb0KwdHtW9k7bS2mw= sha1:/yWmYJIG6XqO2h8ySuvNfmmzNUA= Xref: csiph.com alt.folklore.computers:166625 comp.sys.raspberry-pi:12506 David Wade writes: > All the IBM Mainframe "VM" operating systems consist of at least two > operating systems. > > CP which is often called VM, which is there to provide virtual > Machines. Originally these were pretty basic Virtual Machines which > looked exactly like a real S/370 to any program running in them. > > Internally CP has a large number of control blocks which are chained > together to manage the real hardware, the virtual machines and virtual > hardware, and how they are mapped. I am not aware of any stack. > > There is some use of OS type register save areas. > > traditionally, when used to provide an interactive computing > environment, CP was used to provide each used with a Virtual 370. > > The user then loads the CMS Operating system into the VM. CMS is a > single user operating system that provides a native CMS environment > and DOS and OS emulated environments. Internally it uses OS style > call/save/return mapping. > > I don't believe that modern Z hardware has a hardware stack. There are > still no PUSH/POP type instructions. For languages that need a stack > generally a stack area is allocated when a program is loaded and one > of the 16 General Purpose Registers is then used as a stack pointer, > but in general it has to be incremented/decremented by a second > instruction... original cp67 had a form of (software) stack ... 100 pre-allocated save areas. all calls/return were done by SVC call ... SVC interrupt handler would allocate/deallocate savearea for use by called routine. the svc call accounted for significant percentage of total CPU time spent in the kerenel. As undergraduate in the 60s, I made two changes, 1) svc call routine when it ran out of pre-allocated saveareas would extend the number of saveareas by calling the page allocation routine with special parameter ... that would look for first non-changed page for replacement (didn't require delay waiting for write-out replacing changed page) and 2) there were a whole bunch of routines that were simple call/return ... and I changed them to straight BALR/BR call/return and to use a dedicated save area in page0 (works in multiprocessor since each processor has its own dedicated page0). I also cut the instruction time in the SVC call/return by 2/3rds. I also made a whole lot of other pathlength optimizations ... in same cases improvement by factor of 100. Overall as undergraduate in the 60s, I reduced CP67 kernel CPU time by 3/4s. A lot of this was picked up and shipped in standard CP67 product. Part of presentation that I made at 60s SHARE user group meeting http://manana.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14 as undergraduate I was hired by the univ. to be responsible for production operating systems. the above presentation includes references to changes I made of os/360. On 709 IBSYS tape-to-tape (with 1401 front-end doing tape<->unitrecord student fortran jobs ran under 1second elapsed time). Initial move to os/360 360/65 (360/67 running as 360/65), student fortran jobs ran over minute ... because of enormous disk i/o intensive operation. Adding HASP (spooling system), cut elapsed time/job to a little over half a minute. I started hand-crafted OS/360 system build/sysgen to carefully place/order system data on disk which got it down to a little under 13seconds. For CP67 I also redid a lot of the I/O, added ordered seek queuing and for page activity, chained multiple page transfers into single I/O channel program. I also implemented dynamic adaptive resource manager (frequently called "fair share" for default resource policy) http://manana.garlic.com/~lynn/subtopic.html#fairshare I also did global LRU, clock-like page replacement algorithm ... this was at a time when the academic papers were all about local LRU. some past posts http://manana.garlic.com/~lynn/subtopic.html#clock I've mentioned that when Jim Gray left research for Tandem, he palmed off bunch of stuff on me: http://manana.garlic.com/~lynn/2016d.html#104 Is it a lost cause? At Dec81, ACM SIGOPS, Jim asked me if I could help one of his co-workers at Tandem get his Stanford PHD ... which was on global LRU page replacement. The "local LRU" forces (from the late 60s) were strongly lobbying Stanford to not award any PHD that had to do with local LRU. Jim knew I had a lot of performance data comparing local LRU CP67 and global LRU CP67 implementations (showing global LRU much better) ... much of the other claims on the subject were just opinion and hand waving. Past post on the subject http://manana.garlic.com/~lynn/2006w.html#46 with this reply that I wrote http://manana.garlic.com/~lynn/2006w.html#email821019 aka it took me almost a year to get IBM management to send a replay. Conjecture is that IBM management thought it was a form of punishment because they blamed for online computer conferencing on the internal network (larger than the arpanet/internet from just about the beginning until sometime mid-80s). Folkore is that when the corporate management committee were told about online computer conferencing (and the internal network), 5of6 wanted to fire me. Some past posts http://manana.garlic.com/~lynn/subnetwork.html#cmc and http://manana.garlic.com/~lynn/subnetwork.html#internalnet -- virtualization experience starting Jan1968, online at home since Mar1970