Why these original FORTRAN quirks?
in [Fortran]
|
From: Pierre Asselin on 20 Nov 2006 11:23 In comp.lang.fortran jmfbahciv(a)aol.com wrote: > In article <1163972895.598307.164830(a)e3g2000cwe.googlegroups.com>, > "Terence" <tbwright(a)cantv.net> wrote: > >(Various) > >> >> [ load time relocation ] > >> > > >> >Probably because of the move to shared libraries. You can't do relocation > >> >if different processes map the same code to different addresses. > >> > >> Of course you can do this. As TW would remark, "All it takes > >> is a small matter of programming." > > > >"Relocating code" is what any linker does with your Fortran subroutine > >and function object code. [ ... ] > Your post was written from the POV of an app programmer. Now > try to think from the POV of an OS developer who has to place > your EXE code into memory and arrange to have it executed. Seconded. Note the bit (mine) about shared libraries in the quoted text. If you want to relocate shared code you have to do it copy-on-write and then it's no longer shared, is it. I will amend my earlier statement. You *can* do the relocation even if different processes map the same code to different virtual addresses, but it's a bad idea. -- pa at panix dot com
From: jmfbahciv on 21 Nov 2006 09:25 In article <ejskqj$864$2(a)reader2.panix.com>, pa(a)see.signature.invalid (Pierre Asselin) wrote: >In comp.lang.fortran jmfbahciv(a)aol.com wrote: >> In article <1163972895.598307.164830(a)e3g2000cwe.googlegroups.com>, >> "Terence" <tbwright(a)cantv.net> wrote: >> >(Various) >> >> >> [ load time relocation ] >> >> > >> >> >Probably because of the move to shared libraries. You can't do relocation >> >> >if different processes map the same code to different addresses. >> >> >> >> Of course you can do this. As TW would remark, "All it takes >> >> is a small matter of programming." >> > >> >"Relocating code" is what any linker does with your Fortran subroutine >> >and function object code. [ ... ] > >> Your post was written from the POV of an app programmer. Now >> try to think from the POV of an OS developer who has to place >> your EXE code into memory and arrange to have it executed. > >Seconded. Note the bit (mine) about shared libraries in the quoted >text. If you want to relocate shared code you have to do it >copy-on-write and then it's no longer shared, is it. No,no,no,no. I think you and I have different meanings of relocate. If the monitor relocates a segment of code, the physical address changes are invisible to the app's eye. You can force a monitor to place your piece of app code at a specificed physical location, but most apps will not. This physical address forcing only makes sense for device drivers. IMO, device drivers should never be an application because of security holes they create. > >I will amend my earlier statement. You *can* do the relocation even if >different processes map the same code to different virtual addresses, >but it's a bad idea. That all depends on what your are trying to do. If you are trying to nail down your code around the two physical addresses that the foobar device will write into when it's done with its I/O list, nobody can "reloacte" that away. OTOH, if your code nails itself down unnecessarily to addrA and addrB and those two locations get blasted with Cosmic Ray's gun, you had better have 5K core of error trapping and handling in memory. /BAH
From: Terence on 21 Nov 2006 15:48 > Your post was written from the POV of an app programmer. Now > try to think from the POV of an OS developer who has to place > your EXE code into memory and arrange to have it executed. Well, I started from that end with IBM in 1961, especially early Fortran compilers and 1401 mini-operating systems and 1460 communications control software. It's just a reasonable "recent" POV after later becoming a developer who had "been there" with most of the underlying techniques. After years of management I re-entered University to follow an M.Sc in computer theory and design and was surprised how much fundamental set theory was needed to understand "why" things are the way they are in engineering implementions of computers, and also learn why we use some weird algorithms to accomplish important software tasks.
From: jmfbahciv on 22 Nov 2006 08:59 In article <1164142084.437286.67300(a)h54g2000cwb.googlegroups.com>, "Terence" <tbwright(a)cantv.net> wrote: >> Your post was written from the POV of an app programmer. Now >> try to think from the POV of an OS developer who has to place >> your EXE code into memory and arrange to have it executed. > >Well, I started from that end with IBM in 1961, especially early >Fortran compilers and 1401 mini-operating systems and 1460 >communications control software. 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. >It's just a reasonable "recent" POV >after later becoming a developer who had "been there" with most of the >underlying techniques. After years of management I re-entered >University to follow an M.Sc in computer theory and design and was >surprised how much fundamental set theory was needed to understand >"why" things are the way they are in engineering implementions of >computers, and also learn why we use some weird algorithms to >accomplish important software tasks. My background is operating systems that had the "just in time" philosophy about resources; this deeply affects when relocation happens to code. /BAH
From: Pierre Asselin on 22 Nov 2006 10:02
In comp.lang.fortran jmfbahciv(a)aol.com wrote: > In article <ejskqj$864$2(a)reader2.panix.com>, > pa(a)see.signature.invalid (Pierre Asselin) wrote: > > > >[ ... ] If you want to relocate shared code you have to do it > >copy-on-write and then it's no longer shared, is it. > No,no,no,no. I think you and I have different meanings of relocate. > If the monitor relocates a segment of code, the physical address > changes are invisible to the app's eye. But I'm talking about *virtual* addresses. If shared code is not position independent it has to be mapped at the same virtual address by everyone, or else it has to be relocated --at the cost of private copies of any page with a relocation, i.e. no longer shared. -- pa at panix dot com |