Why these original FORTRAN quirks?
in [Fortran]
|
From: Anne & Lynn Wheeler on 1 Nov 2006 14:08 pa(a)see.signature.invalid (Pierre Asselin) writes: > Probably because of the move to shared libraries. You can't do relocation > if different processes map the same code to different addresses. > > AFAIK relocation is still used when linking statically. aka another os/360 characteristic of relocatable adcons that were randomly distributed thru-out code and data. other systems have had conventions for doing shareable code/libraries such that location specific details were in separate process control structures and that execution convention accessed their location specific information with register-based operations (i.e. registers were part of process and address space specific operation ... as well as the associated process control structures). I fiddled with this a lot for the original shared segment stuff that I built on top of the paged mapped filesystem that I did for cms in the early 70s (originally on cp67 platform). http://www.garlic.com/~lynn/subtopic.html#mmap most of cms used os/360 derived assemblers, compilers, and linker/loader ... so about the only place you could fiddle all the default relocable address constant conventions was in assembler implemented applications: http://www.garlic.com/~lynn/subtopic.html#adcon vm370/cms picked up a trivially small subset of the implementation for product release as something they called DCSS (discontiguous shared segments) ... the vm370 kernel changes to allow new way of specify shared code ... but at a fixed/common address location .. and cms changes were for code to execute in r/o protected shared storage (but confirming to vm370 kernel changes at fixed location). Note that DWSS was different than DCSS. DWSS was part of the original technology transfer of system/r from sjr to endicott for sql/ds. http://www.garlic.com/~lynn/2006t.html#16 Is the teaching of non-reentrant HLASM coding practices ever defensible? system/r was the original relational/sql implementation, done on vm370 platform http://www.garlic.com/~lynn/subtopic.html#systemr various recent posts this year mentioning DCSS 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/2006.html#31 Is VIO mandatory? http://www.garlic.com/~lynn/2006.html#35 Charging Time http://www.garlic.com/~lynn/2006b.html#4 IBM 610 workstation computer http://www.garlic.com/~lynn/2006b.html#7 Mount a tape 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#24 Virtual memory implementation in S/370 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/2006n.html#5 Not Your Dad's Mainframe: Little Iron http://www.garlic.com/~lynn/2006n.html#14 RCA Spectra 70/25: Another Mystery Computer? http://www.garlic.com/~lynn/2006n.html#45 sorting http://www.garlic.com/~lynn/2006o.html#27 oops http://www.garlic.com/~lynn/2006o.html#53 The Fate of VM - was: Re: Baby MVS??? http://www.garlic.com/~lynn/2006p.html#42 old hypervisor email http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft http://www.garlic.com/~lynn/2006q.html#27 dcss and page mapped filesystem http://www.garlic.com/~lynn/2006r.html#23 50th Anniversary of invention of disk drives http://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's? http://www.garlic.com/~lynn/2006s.html#17 bandwidth of a swallow (was: Real core) http://www.garlic.com/~lynn/2006t.html#15 more than 16mbyte support for 370
From: glen herrmannsfeldt on 1 Nov 2006 18:03 In comp.lang.fortran Anne & Lynn Wheeler <lynn(a)garlic.com> wrote: > aka another os/360 characteristic of relocatable adcons that were > randomly distributed thru-out code and data. For many system utility programs and OS/360 Fortran compiler code they were pretty much mixed. Many system macros generate a branch (BAL) over an argument list containing adcons to the appropriate SVC instruction. There is much discussion about newer processors with 256 byte cache lines and separate data and instruction cache running slower mixing data and instructions in the same cache block. I believe that PL/I generates a separate CSECT for static data including relocatable adcons. I don't know about other compilers, such as VS Fortran. -- glen
From: Peter Flass on 1 Nov 2006 18:33 Steve O'Hara-Smith wrote: > On Tue, 31 Oct 2006 22:47:56 GMT > Peter Flass <Peter_Flass(a)Yahoo.com> wrote: > > >>Steve O'Hara-Smith wrote: > > >>> Cue many people to tell us where relocation is still in active >>>use and why it's better than PIC or memory mapping :) >>> >> >>As I understand PIC, it is basically what we used to call >>"self-relocating" code. > > > Not a term I ever came across. AIUI PIC mostly involves using > relative addressing exclusively. > That's even worse. We wrote self-relocating code on 360s, which would update all its address constants in place to relocate itself wherever it was loaded. At least that plus base-displacement addressing insured we'd only suffer a bit of overhead once.
From: Peter Flass on 1 Nov 2006 18:39 Gordon Sande wrote: > > So my take is that it is an important tool for implementors of operating > systems, and such, but of little import for writers of larger, typically > user, software systems. > You may not know it, but you probably "use" it if you write any code for shared libraries. The compiler will generate it based on a command-line switch, etc.
From: Brian Inglis on 1 Nov 2006 20:58
On Wed, 1 Nov 2006 10:23:32 +0000 in alt.folklore.computers, Steve O'Hara-Smith <steveo(a)eircom.net> wrote: >On Tue, 31 Oct 2006 10:12:38 -0800 >glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > >> Steve O'Hara-Smith wrote: >> >> (snip) >> >> > Cue many people to tell us where relocation is still in active >> > use and why it's better than PIC or memory mapping :) >> >> PIC tends to be slower on most processors, such that it isn't > > Hmm that's a surprise. ISTR using relative addressing as an >optimisation back in the days I wrote Z80 assembler a lot and surely PIC is >mostly using relative addressing exclusively. I had occasionally wondered >why it was not the default. > >> the default when it isn't needed. Memory mapping is usually on >> to coarse of boundaries, maybe 4K. (At least for link time relocation.) It's not the default because it's slower, and it's slower because the current PC/IP address has to be added to the relative address to get a virtual address before being translated thru the segment and/or page directory and/or page tables to get a physical address. Maybe need to add a relative branch buffer to the microarchitecture to keep the pipes full? -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply |