Why these original FORTRAN quirks?
in [Fortran]
|
From: Pierre Asselin on 1 Nov 2006 09:17 In comp.lang.fortran Steve O'Hara-Smith <steveo(a)eircom.net> wrote: > 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. AFAIK relocation is still used when linking statically. -- pa at panix dot com
From: krw on 1 Nov 2006 09:24 In article <ei7lj4$8qk_010(a)s868.apx1.sbo.ma.dialup.rcn.com>, jmfbahciv(a)aol.com says... > In article <k5cdk2t78n3vv3dpav0v5nlqus9j4rrgpg(a)4ax.com>, > Brian Inglis <Brian.Inglis(a)SystematicSW.Invalid> wrote: > >On Mon, 30 Oct 2006 15:34:39 -0600 in alt.folklore.computers, Charles > >Richmond <richchas(a)comcast.net> wrote: > > > >>Brian Inglis wrote: > >>> > >>> [snip...] [snip...] [snip...] > >>> > >>> ...and ISTR their standard drivers went haywire if you didn't clip or > >>> scale the vectors to the paper width: drew right down the edge of the > >>> paper, then started drawing from wherever they ended up, a few feet > >>> away from where they should be plotting. > >>> > >>> I'm a big fan of previewing, to avoid including insignificant outlying > >>> data, and autoscaling, to be able to show all of the data, regardless > >>> of output media size. > >>> Nice to be able to view project plans a few feet high and umpty feet > >>> long on the wall. > >>> > >>"Back in the day", at a PPoE, we taped strips of "butcher paper" > >>to the wall and used Magic Markers to draw our project plans and > >>flows. These were umpty-ump feet wide and tall. > > > >But so lo-tech! ;^> > > ARe you kidding? That's hi-tech. I never used magic markers > (they were too expensive). > > I used blackboards and chalk and erasers. hmmm...I could put > a blackboard up if I'm willing to give up the wall space in > leiu of bookshelves. That would be wonderful. > Ick! Chalk dust. Dry-EErase markers are much nicer. BTW, they make "chalkboard paint" [*]. Paint a wall with it. ;-) [*]Even saw "magnetic paint" at the BORG a few days ago. -- Keith
From: Gordon Sande on 1 Nov 2006 09:28 On 2006-11-01 06:23:32 -0400, Steve O'Hara-Smith <steveo(a)eircom.net> said: > 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. (PIC is Position Independent Code which I understand as location counter based (or relative) addressing.) The last time I can recall seeing anything about PIC was a switch on a Mac compiler for M68000 that said it was possible in some situations but if the relative offsets were too large, as was rather likely, then the option should not be used. IIRC the option was intended for small snippets of code that were prone to loaded frequently, or erratically, like interrupt and device handlers. 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. >> the default when it isn't needed. Memory mapping is usually on >> to coarse of boundaries, maybe 4K. (At least for link time relocation.) > > 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.
From: Eugene Miya on 1 Nov 2006 11:24 In article <eia3bv$8ss_016(a)s880.apx1.sbo.ma.dialup.rcn.com>, <jmfbahciv(a)aol.com> wrote: >At DECUS, one of my first questions to a customer who wanted >to chat with me was his favorite programming lanugague. Then >I could talk about OS and development details using that >lanugages concepts. It's difficult to talk about tech to >somebody who has never used your tools. That's what Xerox discovered. It was like trying to describe BSD style job control to people who had no concept of windowing systems (which even Apple got wrong at first). "Oh SUN workstations: such a waste: you should 15-16 people on one" --from a guy I met at Edwards AFB (Not Rich). --
From: glen herrmannsfeldt on 1 Nov 2006 12:43
Gordon Sande wrote: (snip) > (PIC is Position Independent Code which I understand as location counter > based (or relative) addressing.) > The last time I can recall seeing anything about PIC was a switch on a > Mac compiler for M68000 that said it was possible in some situations > but if the relative offsets were too large, as was rather likely, then > the option should not be used. IIRC the option was intended for small > snippets of code that were prone to loaded frequently, or erratically, > like interrupt and device handlers. I first knew about it in SunOS days. Both the 680x0 and SPARC Sun compilers would optionally generate position independent code. It is needed (in SunOS case, anyway) for dynamic link libraries, which are mapped at different addresses at the same time. Sun supplied libc.a for static linking, and libc.so for dynamic linking, with libc.a not position independent. To generate modified versions of libc.so, they also supply a PIC library. You then extract all the .o files from the special PIC library, add or change any, and then create a new libc.so from those file. This was most commonly done to generate a libc.so that would do hostname resolution through DNS instead of YP/NIS as the standard library did. At least for 680x0 and SPARC PIC is slower, and so not default. I believe that is still true for the other popular architectures today. -- glen |