Going from Fortran IV for CDC to any other Fortran
in [Fortran]
|
Prev: Problem with automatic reallocation of allocatable scalar on assignment
Next: a wiki entry for gfortran
From: Nick Maclaren on 8 Aug 2010 15:52 In article <rKGdnVw8GP01msLRnZ2dnUVZ_jqdnZ2d(a)supernews.com>, Gary L. Scott <garylscott(a)sbcglobal.net> wrote: >>> >>>>> That doesn't tell me for sure whether it was f77 or f66 plus ENTRY as an >>>>> externsion. >>> >>>> The preface says "includes full ANS FORTRAN (X3.9-1978) plus IBM >>>> extensions". >>> >>> Ah. That's more explicit then. >> >> VS Fortran was the compiler I described the history of. > >I use it to this day, in fact last week... Say hello to it from me, please :-) Regards, Nick Maclaren.
From: Ron Shepard on 8 Aug 2010 15:57 In article <1jmwkol.1ngbt631cg29baN%nospam(a)see.signature>, nospam(a)see.signature (Richard Maine) wrote: > I'm fairly sure I > recall some IBM f66 compilers as having ENTRY as an extension. In fact, > I think I recall having some porting pains because both the IBM and CDC > compilers had ENTRY, but with different syntax. One of the "features" of IBM (f66+extension) ENTRY points was that dummy arguments from one entry that was previously called could be accessed by code in subsequent entry calls. That is, one entry point could be called to set the base addresses for some set of dummy arrays, or for some set of scalar variables, and then those scalars and arrays could be used later. The other entry points could then have shorter argument lists, making the code (uh...what is the word I'm looking for...) 'simpler'. :-) In fact, trying to figure out how such code written by other programmers actually worked was a nightmare, and when it came time to port this code to standard f77 machines, it sometimes took quite some effort. In many cases where the 'initialization' occurred at some high level in the code and the later entry calls were several levels down, it required modifying the argument lists for dozens of subroutines to add the missing dummy arguments. Sometimes these arguments were used as read-only variables in the low-level calls (read, but not modified), other times they were used as internal workspace (values did not need to be saved between calls), and other times the arguments defined some global state (values were modified and needed to be saved between calls). The best "fix" for all of these situations was often different within f77. I had to port such code to several different machines, mostly DEC, Harris, Convex, and FPS, but also including some CDC, Cyber, and ETA along the way. Some machines/compilers would take the IBM style code, others wouldn't, so the best solution was to port all of it to f77. Before f90, entry points were the only way to encapsulate data locally within a set of related routines, so unlike many other programmers who tried to avoid entry points entirely, I actually liked using them in many situations, including for example library routines. $.02 -Ron Shepard
From: Gary L. Scott on 8 Aug 2010 16:18 On 8/8/2010 2:57 PM, Ron Shepard wrote: > In article<1jmwkol.1ngbt631cg29baN%nospam(a)see.signature>, > nospam(a)see.signature (Richard Maine) wrote: > >> I'm fairly sure I >> recall some IBM f66 compilers as having ENTRY as an extension. In fact, >> I think I recall having some porting pains because both the IBM and CDC >> compilers had ENTRY, but with different syntax. > > One of the "features" of IBM (f66+extension) ENTRY points was that > dummy arguments from one entry that was previously called could be > accessed by code in subsequent entry calls. That is, one entry > point could be called to set the base addresses for some set of > dummy arrays, or for some set of scalar variables, and then those > scalars and arrays could be used later. The other entry points > could then have shorter argument lists, making the code (uh...what > is the word I'm looking for...) 'simpler'. :-) In fact, trying to > figure out how such code written by other programmers actually > worked was a nightmare, and when it came time to port this code to > standard f77 machines, it sometimes took quite some effort. In many > cases where the 'initialization' occurred at some high level in the > code and the later entry calls were several levels down, it required > modifying the argument lists for dozens of subroutines to add the > missing dummy arguments. Sometimes these arguments were used as > read-only variables in the low-level calls (read, but not modified), > other times they were used as internal workspace (values did not > need to be saved between calls), and other times the arguments > defined some global state (values were modified and needed to be > saved between calls). The best "fix" for all of these situations > was often different within f77. > > I had to port such code to several different machines, mostly DEC, > Harris, Convex, and FPS, but also including some CDC, Cyber, and ETA > along the way. Some machines/compilers would take the IBM style > code, others wouldn't, so the best solution was to port all of it to > f77. Before f90, entry points were the only way to encapsulate data > locally within a set of related routines, so unlike many other > programmers who tried to avoid entry points entirely, I actually > liked using them in many situations, including for example library > routines. I used to use "initialization" entry points with subsequent calls having shorter argument lists (but with matching types with the subroutine). I stopped doing it when I found that others had trouble following the logic. > > $.02 -Ron Shepard
From: glen herrmannsfeldt on 8 Aug 2010 18:10 Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote: (snip) > One of the "features" of IBM (f66+extension) ENTRY points was that > dummy arguments from one entry that was previously called could be > accessed by code in subsequent entry calls. That is, one entry > point could be called to set the base addresses for some set of > dummy arrays, or for some set of scalar variables, and then those > scalars and arrays could be used later. The other entry points > could then have shorter argument lists, making the code (uh...what > is the word I'm looking for...) 'simpler'. :-) I think that isn't quite right, at least for Fortran IV. From "S/360 and S/370 Fortran IV": "Arguments that were received by value at some previous use of the subprogram need not appear in the argument list of the ENTRY statement. Arguments that were received by location must appear." They use call by value result for scalars, and call by reference (location) for arrays. (Also, dummy arguments enclosed in slashes.) So, only scalars keep their value, and not their base address. (Note that storing the address would give strange results, as changes to the base variable would change the value seen in the subroutine.) I don't have a VS Fortran manual, so it might have changed, but likely not, other than removing the feature. For S/360 (and successors) it takes one instruction to reference a local variable, but two to reference a variable by reference. Call by value result is, in most cases, more efficient. > In fact, trying to > figure out how such code written by other programmers actually > worked was a nightmare, and when it came time to port this code to > standard f77 machines, it sometimes took quite some effort. In many > cases where the 'initialization' occurred at some high level in the > code and the later entry calls were several levels down, it required > modifying the argument lists for dozens of subroutines to add the > missing dummy arguments. Well, you could also copy the value to a SAVEd variable for later use. > Sometimes these arguments were used as > read-only variables in the low-level calls (read, but not modified), > other times they were used as internal workspace (values did not > need to be saved between calls), and other times the arguments > defined some global state (values were modified and needed to be > saved between calls). The best "fix" for all of these situations > was often different within f77. -- glen
From: Terence on 8 Aug 2010 19:21
On Aug 9, 12:08 am, nos...(a)see.signature (Richard Maine) wrote: > Terence <tbwri...(a)cantv.net> wrote: > > Am I correct in thinking this first use sets LCM to 120000 bytes (a > > CDC use of Fortran) or would this be 120000 BITS? It cannot be a bit > > value because of that "2". > > LCM=120000B > > Variable values aren't bytes, bits, or any units. They are just numbers. > At least that is so in Fortran (and almost all computer languages). The > programmer's intent can be for those numbers to represent numbers of > some unit, but you won't find that in the language syntax. > > Numbers in Fortran have a base, but not units. Binary and hex would be > bases. Bits and bytes are units. I think I detect a confusion between > the two. > > CDC machines of that era did not have bytes. At all. > > Somewhat oddly, the B in this syntax on a CDC indicates octal. It is > just my speculation, but I suppose that they (correctly) figured that > using the letter O for such a thing would be prone to being misread as a > digit 0. I also think there was a bit of a notion that octal was just > sort of a shorter notation for a value that one might think of as > binary. It is so trivial to translate octal to binary in one's head that > I think casual terminology sometimes blurred the difference. > > If this represents something about memory (as is plausible - the CM in > LCM might stand for core memory), the units are probably 60-bit words. > That's the units that memory was measured in. As noted previously, > characters were 6 bits, but the machine could not physically address > individual characters and there wasn't really a term used to refer to > the storage used by a character. On occasion, you might here someone > talking about the machines having a 6-bit byte, but I don't consider > that accurate; they just didn't have bytes of any size - only words. > > -- > Richard Maine | Good judgment comes from experience; > email: last name at domain . net | experience comes from bad judgment. > domain: summertriangle | -- Mark Twain Thank your Richard! So 120000B is 120000 octal. I noticed a comment somewhere else about getting memory in chunks of "100 octal" or 64 bytes. So that value is 10 times 64 times 64 = 40960 or 40k units of storage words. Whereafter, the code checks it hasn't asked for as much as that top value in a series of re-allocations of common (which I have switched to named common for F77 compiling and better availability). This program did have output format statements that asked for Octal and did it by saying "O12" where more usually one asks for "I12" (to get a same-length different radix result, of course). But the presence of the 120000B after using O for octal elsewhere, made me think that B couldn't mean Octal in that statement. Now I know. But both my "F77" manuals actually say "F77" all over the texts; so the issuers did think they had an F77 and not an F66 product to describe (one is for Burroughs B22, the other is IBM PC AT). As to the suggestion to go straight to DVF without pausing in F77 is that far too much rewriting plus module interfacing would be needed; also there is no distinction in this program between integer and float storage units, so memory space is carved up as needed as text, integer and floating point arrays. No way I could easily write the interfaces. |