Why these original FORTRAN quirks?
in [Fortran]
|
From: Charlie Gibbs on 22 Nov 2006 13:22 In article <ek1l45$8qk_003(a)s853.apx1.sbo.ma.dialup.rcn.com>, jmfbahciv(a)aol.com (jmfbahciv) writes: > And didn't IBM develop a philosophy of nailing down physical > addresses before anything can get started? This makes sense > if your sysetm is a data processing production system. You do > not want to start a job that needed a resource which doesn't exist > before the job is started. > > I'm not saying this is "wrong". I'm saying that it's a different > approach that has different side effects than waiting until > the second the resource is needed to provide it. Indeed. It's even possible to get into resource allocation deadlocks if you don't have everything reserved ahead of time. In a mindset that insists that a job make it to completion once it's started, the trade-offs are a bit different. (Mind you, few people understand such a mindset these days - thanks to Microsoft, crashes and forced cancellations are accepted as normal.) -- /~\ cgibbs(a)kltpzyxm.invalid (Charlie Gibbs) \ / I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
From: CBFalconer on 22 Nov 2006 15:23 Charlie Gibbs wrote: > jmfbahciv(a)aol.com (jmfbahciv) writes: > >> And didn't IBM develop a philosophy of nailing down physical >> addresses before anything can get started? This makes sense >> if your sysetm is a data processing production system. You do >> not want to start a job that needed a resource which doesn't exist >> before the job is started. >> >> I'm not saying this is "wrong". I'm saying that it's a different >> approach that has different side effects than waiting until >> the second the resource is needed to provide it. > > Indeed. It's even possible to get into resource allocation deadlocks > if you don't have everything reserved ahead of time. In a mindset > that insists that a job make it to completion once it's started, the > trade-offs are a bit different. (Mind you, few people understand > such a mindset these days - thanks to Microsoft, crashes and forced > cancellations are accepted as normal.) IIRC it is sufficient to describe all non-shareable resources by an integer, and insist on accessing those in strictly increasing numerical descriptions, while releasing them in the inverse order. -- Chuck F (cbfalconer at maineline dot net) Available for consulting/temporary embedded and systems. <http://cbfalconer.home.att.net>
From: Anne & Lynn Wheeler on 22 Nov 2006 20:44 jmfbahciv(a)aol.com writes: > And didn't IBM develop a philosophy of nailing down physical > addresses before anything can get started? This makes sense > if your sysetm is a data processing production system. You do > not want to start a job that needed a resource which doesn't exist > before the job is started. > > I'm not saying this is "wrong". I'm saying that it's a different > approach that has different side effects than waiting until > the second the resource is needed to provide it. > > My background is operating systems that had the "just in time" > philosophy about resources; this deeply affects when relocation > happens to code. os/360 linker/loader resolved (relocatable address constant) addresses at the time the application was loaded (originally "real" addresses, but later on, applications were executed in virtual address space rather than real). my complaints with the os/360 convention wasn't particularly the resolving ... it was that the convention had the relocation address constants distributed thruout the executable image. that caused problems when i did paged mapped filesystem for cms in the early 70s, it wasn't possible to just page map the executable image and then start execution ... the executable image had to be page mapped and then the linker/loader had to run thru (essentially) random locations in the executable image .... swizzling the relocatable address constants. this requires that some (nearly random) number of pages have to be prefetched by the link/loader and modified (before application execution can be begin). misc. past posts about doing page mapped filesystem support for cms http://www.garlic.com/~lynn/subtopic.html#mmap furthermore, it made impossible the page mapping of the same executable image into different virtual address spaces at different virtual addresses. misc. past post about trying to support page mapping the same executable image into different virtual address spaces at potentially different virtual addresses http://www.garlic.com/~lynn/subtopic.html#adcon other aspects of os/360 was that physical disk storage tended to be pre-allocated before the application started execution. on the other hand, from the start, the cms filesystem would dynamically each physical disk record as it was required. os/360 filesystem tended to get very good file locality ... while the cms mechanism could result in nearly random location for a file's physical records. when i did the cms filesystem enhancement for page mapping, i also added some semantics for supporting a degree of contiguous allocation. for lots of other drift .... old email discussing r/o protection of shared images ... in the following "BNR" refers to Bell Northern Research This is discussing "new" method for "protecting" shared segments introduced with release 3 of vm370. Originally, CMS had been reorganized to take advantage of the 370 "segment protect" feature. when that feature was dropped from 370 (as part of helping 370/165 meet schedule for retrofitting virtual memory), vm370 had to revert to the key-protect games used by cp67 for shared page protection. The vm370 release 3 changes allowed, eliminated protection. instead, there was a page scan whenever there was task switch ... to check if the previous task had modified any shared pages. if a shared page had been found to be modified, it was discarded (and any subsequent reference would cause a page fault and retrieve of an unmodified copy from disk). with multiprocessor support, they then had to add a unique copy of shared pages for every running processor. the email also mentions performance enhancement to not bother with protection ... allowing any application in one address space to corrupt (shared) executable images potentially in use by large number of other applications. From: wheeler Date: 04/05/79 20:40:23 FYI; BNR has done some testing on what the release 3 changed page checking is costing them. A 4-5 segment program moved into a discontiquous shared system was requiring about 10% more CPU to complete than running as a module (the changed page checking more than offset any reduction in CPU gained by not doing as much paging and not doing the I/O to load the module). The release 6 not checking code appears to worse than useless for most users (who ever thot of it in the 1st place). Most of the people who are in the tightest CPU bind also have the most users (possibly 200+ plus), it wouldn't take very many incidents of accidental, unpredictable segment modification to completely blow away all possible thru-put gains of using it. Maybe that could be minimized by having a timer driven routine which would run around once every 2-3 minutes checking for any changed pages (which were not be checked for) and abend CP (SVC 0). That would bring the system down and back-up again clean with a minimum of service disruption to the users. The other alternative is for 15-30 minutes to elapsed where everybody got the fealing that something was wrong, but nobody could quite fiqure out what. Hopefully a system programmer would be along to get them out of the mess (also PTR could even abend faster if a shared, changed page was ever selected). This also eliminates all the nasty buGs associated with DMKVMA and unsharing. You get a nice, clean abend that nobody has to worry about fixing (could even change CP so that it even bypasses taking a dump). I haven't heard of anybody yet who is planning on using the release 6 feature to save the overhead of checking for changed pages in CMS. Maybe some installation that doesn't have very many people dependent on CMS (Of course in that case why are they worrying about the performance?). .... snip ... past posts about the vm370 release 3 change for "protecting" shared pages http://www.garlic.com/~lynn/2005e.html#53 System/360; Hardwired vs. Microcoded http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line http://www.garlic.com/~lynn/2005f.html#46 Moving assembler programs above the line http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP http://www.garlic.com/~lynn/2006.html#13 VM maclib reference http://www.garlic.com/~lynn/2006m.html#26 Mainframe Limericks http://www.garlic.com/~lynn/2006m.html#54 DCSS http://www.garlic.com/~lynn/2006u.html#26 Assembler question
From: Anne & Lynn Wheeler on 23 Nov 2006 01:10 The first problem with taking an existing application and setting it up for common, shared executable across multiple virtual address spaces involved making sure that the executable image would work in read-only, protected storage. A lot of the applications from the period tended to have a lot of temporary working storage spread through-out the program. Portions of the code typically had to be rewritten to convert it for use in read-only, protected execution. I had originally done the CMS paged mapped filesystem support and the shared execution support in the early 70s. A very small subset of that support was included in release 3 under the label "DCSS" (or discontiguous shared segments). I had support that could take shared executable image directly from the CMS (paged mapped) filesystem. However, not only was there the relocatable address constant issue ... discussed in the previous posts http://www.garlic.com/~lynn/2006u.html#54 Why these original FORTRAN quirks? http://www.garlic.com/~lynn/2006u.html#60 Why these original FORTRAN quirks? but also modifying existing application code that made used of internal working storage. Recent post that has quite a bit of RED editor discussion http://www.garlic.com/~lynn/2006u.html#26 Assembler question included an email from 3nov78 that makes a passing reference to modifying RED editor for execution in shared, protected storage. this refers to RED having the necessary modifications between 3nov78 and 23may79. the "re-genmoding" (in the following email) refers to the CMS command with the modifications that supports automatically invoking the shared execution invokation from paged mapped filesystem. NED is another (internal) editor from the period. APL is the APL interpreter. DSM is the "script" document format application ... i.e. supporting both script "dot" formating commands as well as GML (generalized markup language) format commands ... misc. past posts mentioning GML, SGML, HTML, XML, etc http://www.garlic.com/~lynn/subtopic.html#sgml From: wheeler Date: 05/23/79 19:14:12 I've setup up the following and checked for storage alterations RED NED APL and DSM just by loading and re-genmoding them. RED and NED have been regen'ed with just segment 2 shared (RED has another 5-6 pages and NED has another 2-3 pages). APL was gen'ed with segments 2, 3, and 4 shared (it has another 1 or 2 pages). DSM was gen'ed with segments 2 and 3 shared (it has another 14-15 pages, it would be worthwhile to obtain the original DSM text decks and dummy the ending module location up to the next segment boundary so that segment 4 could also be shared). EDGAR is just slightly under 16 pages. It will also be necessary to obtain the original text for it so that its ending address is rounded up to a segment boundary so that it will have a shared segment. That takes care of the immediate modules that I know about that can be shared. -- also re: APL; the APL we are running is 2.1 from PID. Talking to the science centers it was suggested that we obtain LA's APL for our production system. Among its other enhancements, their comment was that at least with LA's APL we would receive support as compared to the PID version (I assume they mean to imply PID version isn't answering and/or correcting any bug reports). .... snip ... misc. past posts mentiong DCSS: http://www.garlic.com/~lynn/2001c.html#2 Z/90, S/390, 370/ESA (slightly off topic) http://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390 http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...) http://www.garlic.com/~lynn/2002o.html#25 Early computer games http://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning) http://www.garlic.com/~lynn/2003f.html#32 Alpha performance, why? http://www.garlic.com/~lynn/2003g.html#27 SYSPROF and the 190 disk http://www.garlic.com/~lynn/2003n.html#45 hung/zombie users ... long boring, wandering story http://www.garlic.com/~lynn/2003o.html#42 misc. dmksnt http://www.garlic.com/~lynn/2004d.html#5 IBM 360 memory http://www.garlic.com/~lynn/2004f.html#23 command line switches [Re: [REALLY OT!] Overuse of symbolic http://www.garlic.com/~lynn/2004l.html#6 Xah Lee's Unixism http://www.garlic.com/~lynn/2004m.html#11 Whatever happened to IBM's VM PC software? http://www.garlic.com/~lynn/2004o.html#9 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2004o.html#11 Integer types for 128-bit addressing http://www.garlic.com/~lynn/2004p.html#8 vm/370 smp support and shared segment protection hack http://www.garlic.com/~lynn/2004q.html#72 IUCV in VM/CMS http://www.garlic.com/~lynn/2005b.html#8 Relocating application architecture and compiler support http://www.garlic.com/~lynn/2005e.html#53 System/360; Hardwired vs. Microcoded http://www.garlic.com/~lynn/2005f.html#45 Moving assembler programs above the line http://www.garlic.com/~lynn/2005g.html#30 Moving assembler programs above the line http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP http://www.garlic.com/~lynn/2005t.html#39 FULIST http://www.garlic.com/~lynn/2006.html#10 How to restore VMFPLC dumped files on z/VM V5.1 http://www.garlic.com/~lynn/2006.html#13 VM maclib reference http://www.garlic.com/~lynn/2006.html#17 {SPAM?} DCSS as SWAP disk for z/Linux http://www.garlic.com/~lynn/2006.html#18 DCSS as SWAP disk for z/Linux http://www.garlic.com/~lynn/2006.html#19 DCSS as SWAP disk for z/Linux http://www.garlic.com/~lynn/2006.html#25 DCSS as SWAP disk for z/Linux http://www.garlic.com/~lynn/2006.html#28 DCSS as SWAP disk for z/Linux http://www.garlic.com/~lynn/2006f.html#2 using 3390 mod-9s http://www.garlic.com/~lynn/2006i.html#23 Virtual memory implementation in S/370 http://www.garlic.com/~lynn/2006i.html#43 virtual memory http://www.garlic.com/~lynn/2006j.html#36 The Pankian Metaphor http://www.garlic.com/~lynn/2006m.html#53 DCSS http://www.garlic.com/~lynn/2006m.html#54 DCSS http://www.garlic.com/~lynn/2006m.html#56 DCSS http://www.garlic.com/~lynn/2006o.html#53 The Fate of VM - was: Re: Baby MVS??? http://www.garlic.com/~lynn/2006q.html#27 dcss and page mapped filesystem http://www.garlic.com/~lynn/2006s.html#17 bandwidth of a swallow (was: Real core) http://www.garlic.com/~lynn/2006t.html#39 Why these original FORTRAN quirks?
From: blmblm@myrealbox.com on 23 Nov 2006 07:47
In article <4564B1BC.6D607D07(a)yahoo.com>, CBFalconer <cbfalconer(a)maineline.net> wrote: > Charlie Gibbs wrote: > > jmfbahciv(a)aol.com (jmfbahciv) writes: > > > >> And didn't IBM develop a philosophy of nailing down physical > >> addresses before anything can get started? This makes sense > >> if your sysetm is a data processing production system. You do > >> not want to start a job that needed a resource which doesn't exist > >> before the job is started. > >> > >> I'm not saying this is "wrong". I'm saying that it's a different > >> approach that has different side effects than waiting until > >> the second the resource is needed to provide it. > > > > Indeed. It's even possible to get into resource allocation deadlocks > > if you don't have everything reserved ahead of time. In a mindset > > that insists that a job make it to completion once it's started, the > > trade-offs are a bit different. (Mind you, few people understand > > such a mindset these days - thanks to Microsoft, crashes and forced > > cancellations are accepted as normal.) > > IIRC it is sufficient to describe all non-shareable resources by an > integer, and insist on accessing those in strictly increasing > numerical descriptions, while releasing them in the inverse order. > IIRC you are right that if you give every resource a unique number and access them in strictly increasing order deadlock is impossible. But I don't think there are any restrictions on the order in which things are released. (Now someone can correct me if I'm wrong. :-)? ) -- B. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor. |