Why these original FORTRAN quirks?
in [Fortran]
|
From: Greg Lindahl on 30 Oct 2006 00:25 In article <lAe1h.41674$X11.28864(a)bignews7.bellsouth.net>, Rostyslaw J. Lewyckyj <urjlew(a)bellsouth.net> wrote: >I don't know that there is a 'usual method' for quoting >in that situation. It goes like this: In article <lAe1h.41674$X11.28864(a)bignews7.bellsouth.net>, Rostyslaw J. Lewyckyj <urjlew(a)bellsouth.net> wrote: >I don't know that there is a 'usual method' for quoting >in that situation. Talk about the first quote. In article <lAe1h.41674$X11.28864(a)bignews7.bellsouth.net>, Rostyslaw J. Lewyckyj <urjlew(a)bellsouth.net> wrote: >I don't know that there is a 'usual method' for quoting >in that situation. Talk about the second quote. The important part is preserving the leading >, that's a signal to anyone replying that they need to preserve the attribution. -- greg
From: Greg Lindahl on 30 Oct 2006 00:36 In article <l711h.488$xw1.226(a)twister.nyroc.rr.com>, Peter Flass <Peter_Flass(a)Yahoo.com> wrote: >Now fewer and fewer people develop software that is used by more and >more people. The market for compilers is becoming more limited, but the >cost of developing a compiler is not decreasing nearly as rapidly, so >the prices of commercial compilers have jumped. I don't think there's proof of any of this. BTW, the cost of developing a compiloer varies widely by organization; the QLogic (PathScale) compiler team is about 1/40 the size of Intel's compiler team. And most of the cost of the Fortran compiler in both organizations is shared with the C and C++ compilers. When considering the size of the market, you should also include all the folks using Matlab, as they used to be people in the Fortran market. The fact that conventional Fortran compilers have failed these people is unfortunate, but it's still a reachable market. -- greg
From: jmfbahciv on 30 Oct 2006 07:17 In article <m3vem36n18.fsf(a)garlic.com>, Anne & Lynn Wheeler <lynn(a)garlic.com> wrote: >jmfbahciv(a)aol.com writes: >> CAreful. The linkers and loaders aren't separate. What is even >> worse is that the kiddies who think they know how machines work, >> are not aware of the reasons for linkers and loaders; they assume, >> rightly from their experience, that it is all one procedural step. >> This is a loss of knowledge that is happening right now. > >one of the other things left over from the os/360 real memory days is >figuring out where the program image was to be loaded ... and then >having to swizzle all the "relocatable" address constants that were >frequently randomly distributed thru-out the program image. Yes. Is the word "relocatable" even used in CS classes anymore other than as buzzword to sound impressive? > >os/360 compilers and assemblers generated 80byte cards with 12-2-9 >(0x02 hex) in column followed by ESD, TXT, RLD, etc. > >ESD cards gave the "external" symbol information ... the names of entry >points into the program and names of external applications. > >TXT cards contained up to 56 bytes of actual program instructions and >data > >RLD cards contained the location (displacement in the program) of >"relocatable" address constants. > >once the linker/loader had decided on the address for loading the >program image ... it then had to run thru all the RLD information, >finding the associated "relocatable" address constants and swizzling >their values to correspond to actual memory address. that is in >addition to "resolving" addresses (swizzling them also) of external >program entry points. I think this mess is why EXEs were invented ;-). > >recent posting discussing issues with os/360 convention of relocatable >address constants <snip list--sorry, Lynn> /BAH
From: Paul van Delst on 30 Oct 2006 09:41 Rostyslaw J. Lewyckyj wrote: > Not if some of the modernizers get their way :) > Another thing is that the older Fortrans were fairly small and simple > so that not-a-programming-professionals could get their heads around > it and write pretty good programs. The recent elaborations have indeed > enriched the language. But... I reckon that's a specious argument. The "newer" Fortrans are not that complicated that a "not-a-programming-professional" can get his/her head around it.... and write even more robust, more reusable and more easily maintained code. If an older Fortran version fits the bill for someone to get their work done, great - the newer standards require backwards compatibility, so no fundamental changes need be made to their code. However, there always seems to be this residual "but..." that implies the newer standards took something simple and easy and screwed it up somehow by adding sorely needed functionality. I place this argument in the same category as the "Fortran is a dead language" argument (which, by the way, was expressed at a conference I recently attended.) cheers, paulv -- Paul van Delst Ride lots. CIMSS @ NOAA/NCEP/EMC Eddy Merckx Ph: (301)763-8000 x7748 Fax:(301)763-8545
From: Richard Maine on 30 Oct 2006 12:42
Paul van Delst <Paul.vanDelst(a)noaa.gov> wrote: > The "newer" Fortrans are not that complicated that a > "not-a-programming-professional" can get his/her head around it.... Heck, I had direct experience with that recently. For reasons not relevant here (and I wouldn't want to say bad things in public about our management - I got a formal hand-slap for that once :-)), the work of maintenance of one of my major f90 apps that I did in the early 90's has fallen to a fellow with zero Fortran experience. That group (which I don't work in any more, and haven't for quite a while) is in the middle of a major hardware transition for the servers. This has involved porting the app to a different compiler, a substantially different version of the OS (from Solaris 2.6, I think it was, to whatever the current version is), a different database (from Sybase to PostgreSQL), and a bunch of other stuff. The maintainer, who had zero Fortran experience, but seems competent, has done pretty well at picking it up just by inspection of my code. In one case that I particularly recall, he came to me a bit puzzled because he thought he understood what a particular bit of code looked like it was trying to do, but it didn't seem to be acting as expected. The code in question was building a dynamically-sized pointer array by appending elements, doubling the size as needed, and then reallocating the final result to the right size (a technique that has been discussed here often enough). So the code was heavy in new f90 "stuff" involved. Sure enough, he understood the code well enough, but had found a bug in the Sun compiler (an optimizer bug - one that they now have a patch for). -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain |