Why these original FORTRAN quirks?
in [Fortran]
|
From: glen herrmannsfeldt on 17 Oct 2006 16:56 In comp.lang.fortran Rostyslaw J. Lewyckyj <urjlew(a)bellsouth.net> wrote: (snip on PI and intrinsic functions) > Well yes and no. The intrinsics are not really a part > of the language, though almost. I don't believe any such > functions are mandated for the language in the standard. > They are functions known to the compiler that are a part > of the supporting libraries, and the compiler generates > special execution time calls to the these functions. > (I don't think any of these are evaluated at compile time ) Fortran 66 has intrinsic functions and basic external functions. Basic external functions must exist such that they can be passed as an actual argument to another function. Intrinsic functions can, and usually are, generated inline. Some that are usually generated inline are type conversion, max/min, mod. The max and min series, accepting a variable number of arguments, can't be generated as Fortran functions. (That is, written in standard Fortran.) > Also while the compiler may generate special calls to > its' own versions of these routines by default, > it can be informed to treat these names as user provided > EXTERNAL routines called with the standard subroutine, > function, linkage. Yes, that is one of the uses of the EXTERNAL statement, the other being to pass a subroutine/function name as an actual argument. >> (snip on initializing variables in a DATA statement.) (snip) > The BLOCK DATA subroutine is used to initialize variables > in named COMMONs, and named COMMONs can be positioned in > the overlay under programmer control in the linker. > I know that one can have several different pre compiled > versions of a BLOCK DATA subroutine and link one in to > customize a program without needing to recompile the > other pieces. (I'm not explaining this well :( ) The OS/360 linkage editor is unusual in that it allows one to relink later by being able to read its own output. That, and the rule that if a symbol is defined more than once the first instance is used allows one to replace a routine or initialized COMMON in an already linked routine. (For OS/360, an initialized COMMON from BLOCK DATA is a CSECT, just like executable code. Uninitialized COMMON is a COM section.) OS/360 (linker) rules specify that the COMMON in BLOCK DATA must be at least as long as any other with the same name. (Less strict than the standard, though.) -- glen
From: Terence on 17 Oct 2006 19:07 I see a few of us are still alive! I was flying RAF planes in post-war 1946; Then I worked on a DC-amplifier based teletype output computer for 200 strain gauges an aircraft factory in 1951 and 52 to find why tails fell off (metal fatigue at low temperatures). And later used the Mercury STAR computer for De Havilland "Blue Streak" guidance simulations (using paper tape and big boxes of spare dual-triodes). Then I installed several paper-tape 1620's for IBM in the UK and was involved with Fortran for IBM in the 1961-64 period (and still use F77 in preference to anything else). Yes, I have the 704 manual and others.. I also wrote the card loader that played music pieces on the 1403 printer chain, and a simple tape operating system for the 1401 (and I could go on..). If anybody wants war stories, please feel free to write; I know of others from the period.
From: Richard Maine on 17 Oct 2006 19:22 Rostyslaw J. Lewyckyj <urjlew(a)bellsouth.net> wrote: > Well yes and no. The intrinsics are not really a part > of the language, though almost. I don't believe any such > functions are mandated for the language in the standard. I couldn't quirte follow whether you were talking about Fortran or PL/I, both having been mentioned in prior paragraphs. I don't know enough PL/I to comment, so I won't tr. But in Fortran, the standard intrinsic functions most definitely are part of the language. They are specified in the standard, are required of all compilers, and are in general just as much a part of the language as the syntax is. > (I don't think any of these are evaluated at compile time ) Again, sticking to Fortran, several are all but required to be evaluatable at compile time. The standard doesn't technically distinguish between compile-time and run-time; a standard-conforming processor isn't required to have two such separate parts. But the design definitely envisions such separation, and there are things that are designed to be done at compile time; if they weren't, you wouldn't be able to do much useful in the way of compilation. The list of intrinsics that must be usable at compile time (specifically, the list of intrinsics that are allowed in what are called initialization expressions has grown over the years; in f2003, it is all of them). > Well plain DATA initializes local variables which are kept > in the same CSECT as the code. Theoretically, I suppose, > these variables could be placed into a seperate CSECT with > a special name, which the linker would automatically move > to the root segment, But I don't know of such. I have seen Fortran compilers that put some initialized data into separate CSECTS. In particular, I'm sure I recall things like that in the old CDC compilers. Those compilers were also the ones where it sometimes actually did make a difference whether COMMONs were saved or not. -- Richard Maine | Good judgement comes from experience; email: last name at domain . net | experience comes from bad judgement. domain: summertriangle | -- Mark Twain
From: robin on 17 Oct 2006 20:17 "Lynn McGuire" <nospam(a)nospam.com> wrote in message news:12j7e8oa9c3tj9a(a)corp.supernews.com... > >> On page 44 [1], there is a list of the various symbol tables that the > >> Fortran compiler uses -- there are quite a lot, so "symbol table" is > >> misleading -- and the first entry is "(TEIFNO Table). The number of > >> Fortran statements which have statement numbers must not exceed 1500." > > >For those of you who never encountered a punch-card in anger, it was > >possible to electro-mechanically sort a deck that had been accidently > >dropped - provided that columns 72-80 were numbered in order > > That is columns 73-80. A simpler method was normally used, namely to inscribe a diagonal line across the top of the deck of cards. When cards fell, they fell in batches that could be gathered up and re-assembled in correct order in a minute or two.
From: Rostyslaw J. Lewyckyj on 17 Oct 2006 23:50
glen herrmannsfeldt wrote: > In comp.lang.fortran Rostyslaw J. Lewyckyj <urjlew(a)bellsouth.net> wrote: > (snip on PI and intrinsic functions) > > >>Well yes and no. The intrinsics are not really a part >>of the language, though almost. I don't believe any such >>functions are mandated for the language in the standard. >>They are functions known to the compiler that are a part >>of the supporting libraries, and the compiler generates >>special execution time calls to the these functions. >>(I don't think any of these are evaluated at compile time ) > > > Fortran 66 has intrinsic functions and basic external > functions. Basic external functions must exist such > that they can be passed as an actual argument to another > function. Intrinsic functions can, and usually are, > generated inline. Some that are usually generated inline > are type conversion, max/min, mod. The max and min > series, accepting a variable number of arguments, > can't be generated as Fortran functions. (That is, > written in standard Fortran.) > You are right, and I stand corrected. I was thinking of things like sin({var}) where unless you specified EXTERNAL sin, the compiler chose which of it's library routines to call depending on the type of {var}. I forgot to consider max/min, mod which did sometimes get done at compile time. Though again you could override. I never tried changing the use of any of these names e.g. max=....... . So I don't recall any warnings, or error messages because of these names having that special almost reserved word status. > >>Also while the compiler may generate special calls to >>its' own versions of these routines by default, >>it can be informed to treat these names as user provided >>EXTERNAL routines called with the standard subroutine, >>function, linkage. > > > Yes, that is one of the uses of the EXTERNAL statement, > the other being to pass a subroutine/function name as > an actual argument. > > >>>(snip on initializing variables in a DATA statement.) > > (snip) > > >>The BLOCK DATA subroutine is used to initialize variables >>in named COMMONs, and named COMMONs can be positioned in >>the overlay under programmer control in the linker. >>I know that one can have several different pre compiled >>versions of a BLOCK DATA subroutine and link one in to >>customize a program without needing to recompile the >>other pieces. (I'm not explaining this well :( ) > > > The OS/360 linkage editor is unusual in that it allows > one to relink later by being able to read its own output. > That, and the rule that if a symbol is defined more than > once the first instance is used allows one to replace > a routine or initialized COMMON in an already linked > routine. (For OS/360, an initialized COMMON from > BLOCK DATA is a CSECT, just like executable code. > Uninitialized COMMON is a COM section.) OS/360 > (linker) rules specify that the COMMON in BLOCK DATA > must be at least as long as any other with the same > name. (Less strict than the standard, though.) > I was not thinking of the case of relinking a load module to either replace or add a BLOCK DATA. Here's my example: Suppose you have a long routine with a block of initialized variables. If you put these into a NAMED COMMON then you can compile the subroutine once and compile several BLOCK DATA subroutines on an as needed basis to link with the object of the subroutine (Plus other object decks, also using any linkage editor control cards as needed) without needing to recompile the long subroutine for each different set of initializations. > -- glen |