Why these original FORTRAN quirks?
in [Fortran]
|
From: jmfbahciv on 18 Nov 2006 09:46 In article <VvXZg.21904$O65.12207(a)bignews5.bellsouth.net>, "Rostyslaw J. Lewyckyj" <urjlew(a)bellsouth.net> wrote: >Richard E Maine wrote: >> Rostyslaw J. Lewyckyj <urjlew(a)bellsouth.net> wrote: >> >> >>>Richard E Maine wrote: >> >> >>>>When I was an obnoxious youngster (the young part has changed :-)) still >>>>in undergrad school doing keypunching for some of the senior engineers, >>>>I got my figurative hand slapped for "improving" some of the code on the >>>>fly as a typed. >>>> >>>>In retrospect, I realize that some of my "improvements" weren't.... >> >> >>>Keypunchers are supposed to quickly and accurately convert text written >>>on coding forms, or in some cases other forms, into machine readable >>>media. Anything that slows down this process, such as reading the >>>material for comprehension will tend to slow down the efficiency of the >>>transfer process. This is another reason that the keypuncher should not >>>play at being an editor, or filter. >> >> >> Although that might apply to a person whose job was to be a keypuncher, >> my job was to be an engineering trainee. Keypunching for the "real" >> engineers was just a piece of the job. As a trainee, it actually does >> help to pay attention to what one is doing instead of turning off the >> brain and operating by rote (unless one is training for a position that >> is purely to do the rote operations). >> >> Much like "optimizing" code, doing a good job of optimizing a work >> process requires one to stand back and understand what the larger >> objectives really are. Otherwise you end up optimzing the wrong things. >> In this case, optimizing my throughput as a keypuncher would have been >> detrimental to the most important part of my job as a trainee. >> >> Some of what I did was wrong, as elaborated in the parts I elided above, >> but thinking about what I was doing was not wrong. >> >Yes. As an engineering trainee, apprentice, acolyte, doing some >incidental keypunching, my comments do not apply. >However they apply to the kind of persons that Mizz Barbara was >reminiscing about. >What I can't figure out is what position she was officialy playing? >keypunch operator?, ???. In various comingled posts she mentions >doing programming in some and keypunching in others. I did any work that needed to be done. /BAH
From: jmfbahciv on 19 Nov 2006 09:20 In article <m3lkmtx0zb.fsf(a)lhwlinux.garlic.com>, Anne & Lynn Wheeler <lynn(a)garlic.com> wrote: > >jmfbahciv(a)aol.com writes: >> Of course you can do this. As TW would remark, "All it takes >> is a small matter of programming." > >or lots of SMOP ... misc. posts mentioning SMOP for >doing relocation >http://www.garlic.com/~lynn/subtopic.html#adcon In all cases, the programmer had to be a bit god, IME, of course :-). /BAH
From: Terence on 19 Nov 2006 16:48 (Various) > >> That's true, I was thinking of load time relocation and linking > >> loaders which AFAIK are completely gone. It's been a while since I last > >> looked at the detailed behaviour of a linker but they seem to talk about > >> symbol resolution these days instead of 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." Not even necessary! There was a routine somebody else wrote WAY BACK (I'm not the oldest by a long way), to do automatic relocation of assembled code, by noting what each instruction needed as parameters and so what kind of address types was present and adjusted addresses accordingly. I remember using using information from the technique when I was writing a flow-diagram analyser for assembly programs (before doing the same for Fortran (which was far easier). I later recognised use of this in very sophisticated viruses that alternated real-work code with gererated variable dummy do-nothing code in order to escape detection (and also with two nested levels of encryption to make it tougher to scan), "Relocating code" is what any linker does with your Fortran subroutine and function object code. It's very easy to dump a module and work out how the compiler stores the resulting mixture of code, entry points and segmentation information. I always thought taking things apart help learn hjow to put stuff together. "TW" Private lectures by correspondence...
From: jmfbahciv on 20 Nov 2006 09:10 In article <1163972895.598307.164830(a)e3g2000cwe.googlegroups.com>, "Terence" <tbwright(a)cantv.net> wrote: >(Various) >> >> That's true, I was thinking of load time relocation and linking >> >> loaders which AFAIK are completely gone. It's been a while since I last >> >> looked at the detailed behaviour of a linker but they seem to talk about >> >> symbol resolution these days instead of 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." > >Not even necessary! There was a routine somebody else wrote WAY BACK >(I'm not the oldest by a long way), to do automatic relocation of >assembled code, by noting what each instruction needed as parameters >and so what kind of address types was present and adjusted addresses >accordingly. I remember using using information from the technique when >I was writing a flow-diagram analyser for assembly programs (before >doing the same for Fortran (which was far easier). I later recognised >use of this in very sophisticated viruses that alternated real-work >code with gererated variable dummy do-nothing code in order to escape >detection (and also with two nested levels of encryption to make it >tougher to scan), > >"Relocating code" is what any linker does with your Fortran subroutine >and function object code. It's very easy to dump a module and work out >how the compiler stores the resulting mixture of code, entry points and >segmentation information. I always thought taking things apart help >learn hjow to put stuff together. 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. /BAH
From: Anne & Lynn Wheeler on 20 Nov 2006 11:09
"Terence" <tbwright(a)cantv.net> writes: > "Relocating code" is what any linker does with your Fortran subroutine > and function object code. It's very easy to dump a module and work out > how the compiler stores the resulting mixture of code, entry points and > segmentation information. I always thought taking things apart help > learn hjow to put stuff together. recent posts in this thread mentioning the issue of relocable address constants http://www.garlic.com/~lynn/2006t.html#30 Why these original FORTRAN quirks? http://www.garlic.com/~lynn/2006t.html#39 Why these original FORTRAN quirks? http://www.garlic.com/~lynn/2006u.html#1 Why these original FORTRAN quirks? the issue in the os/360 paradigm (which has been carried on thru today) is that the relocatable objects are called *relocatable address constants* which tend to be liberally distributed thru the executable image. the loader/linker function requires fetching the executable image into the address space and then running thru that image, swizzling the relocatable address constants to correspond to the address the image was loaded. this is one of the big issues that i faced doing paged map filesystem enhancements for cms in the early 70s ... misc. past posts http://www.garlic.com/~lynn/subtopic.html#mmap .... all the pages mapped to virtual address space that contained relocatable address constants first had to be prefetched and modified before execution could even begin ... then the operating system then had the additional overhead of dealing with the modified pages .... even tho the executable image was nominally otherwise unchange. the next issue was attempting to treat page mapped executable images as shared, read-only code ... the same (physical) copy appearing simulataneously in different address space ... possibly at unique address in each address space. unless there is some quantum effects where a relocable address constant can simultaneously take on a large number of different values ... and the appropriate value is automagically provided for the address space that is currently executing ... then it broke down. lots of past posts about dealing with problem of relocatable address constants in a shared segment (same physical copy in different address space ... at potentially different addresses) paradigm. http://www.garlic.com/~lynn/subtopic.html#adcon basically, i had to rewrite the code to remove use of relocatable address constant in programs targeted for such shared segments. other infrastructures that supported such operations out of the box, would have collected all the relocable address constants in a different control structure ... not part of the executable image. each address space would have its own unique instruction address and set of registers. one of the registers would be used to address the control structure containing the appropriately adjusted relocable address constants. |