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: Terence on 10 Aug 2010 01:08 On Aug 10, 10:03 am, mecej4 <mecej4.nyets...(a)opFeramail.com> wrote: > Terence wrote: > > However, I suspect the algorithm needs more that 64K bytes in the > > array it carves up into sub variables. The original source seem to > > request 40960 floating point words which are used three different > > times in three different carvings. > > I believe that the compiler you used (MS Fortran 3.x) had a $LARGE > metacommand to allow the use of arrays that occupied > 64K bytes. However, > if your three arrays need to _coexist_, you need 983K bytes; adding in the > needs of OS, BIOS and code, that will overflow the 20-bit address limits of > 16 bit mode. > > -- mecej4 No, the three "arrays" refered to do not co-exist. There is one variable defined as X(1) in "blank common" (which I named in order to remove all the other variables using that space), which is then referred to in all calls to later subroutines as the passed array start points X(i1),X(i2),..X(80-odd), with three separate assignments of the ix integer set for the three cases (sets of subroutines: input and checking, computations, output reporting). In the subroutines the passed arrays are individually named with their expected sizes as other integer variables. As I said, I've seen this technique a lot in mainframe Fortran IV of the middle 1960's. In personal computers, the use of 20 tapes to save 20 sets of earthquake anakyses is easily replaced by just opening, using and closing the same unitnumber as different file names. I don't beleive the "tapes" are ever used simultaneously. I have received permission to send the original file to persons who feel they might like to have a "go" converting to F90 or later version compilers; in which case my own code to remove the Hollerith assignments. and machine-dependent operations might be called upon. I believe the licencee and potential user, has a GNU fortran. I can also supply a command-line program which compares two text files of up to 160 bytes per line, to allow automatic copying of equivalent equal text, with selection in or out and/or bypass of lines from either files, to make a third combined file. I find it remarkably useful. I believe VEDIT allows something similar.
From: robin on 10 Aug 2010 11:54 "Nick Maclaren" <nmm(a)gosset.csi.cam.ac.uk> wrote in message news:i3op00$57s$1(a)gosset.csi.cam.ac.uk... | In article <4c5f685c$0$56742$c30e37c6(a)exi-reader.telstra.net>, | robin <robin51(a)dodo.com.au> wrote: | > | >Instead of making insulting and derogatory remarks about someone else | >when you are shown up to be incorrect, why don't you take a good look | >at yourself !! | | I recommend that you read the gospel of Matthew, specifically 7:1-5. You and Maine are two of a kind. Neither of you likes to be told you are wrong, and your reaction is to make derogatory remarks about the contributor.
From: Terence on 13 Aug 2010 03:17 I supplied the OP with my re-written F77 version of the Fortran IV earthquake signal-processing program. He then compiled it with his G77 compiler. Unfortunatley, the original program calls the maximum memory it can, then carves this up three times into three distinct uses and mappings of variables. My compiler has no objection to this, since only pointers to memory are passed, and the compilation and linking is error-free, but the OP's G77 points out that the workspace variables passed to the routines vary by type from call to call and therfore gives compiling problems. Another two problem areas are , where SUBORD is defined as REAL SUBORD(1):- But exceeding the array size of (1), fairly common usage if you don'r know the maximunm array size (but I checked it will be 5), gives:- mash.for: In subroutine `divord': SUBORD(1)=MAXORD*0.2 mash.for:2624: warning: SUBORD(2)=MAXORD*0.4 ^ Array element value at (^) out of defined range mash.for:2625: warning: SUBORD(3)=MAXORD*0.6 ^ Array element value at (^) out of defined range mash.for:2626: warning: SUBORD(4)=MAXORD*0.8 ^ Array element value at (^) out of defined range mash.for:2627: warning: SUBORD(5)=MAXORD*1.0 ^ Array element value at (^) out of defined range I thought this was usually acceptable. And more strangely (only the precise element number is objected to):- mash.for: In subroutine `rfft': mash.for:3004: warning: A(NTOT2+4)=A(2) ^ Array element value at (^) out of defined range mash.for: In subroutine `rfsn': mash.for:3119: warning: A(2)=A(NTOT2+4) ^ Array element value at (^) out of defined range To send the original or my version to anybody, I need a note replying to me, to give the real e-mail address as return address.
From: glen herrmannsfeldt on 13 Aug 2010 08:37 Terence <tbwright(a)cantv.net> wrote: > I supplied the OP with my re-written F77 version of the Fortran IV > earthquake signal-processing program. He then compiled it with his G77 > compiler. > Unfortunatley, the original program calls the maximum memory it can, > then carves this up three times into three distinct uses and mappings > of variables. > My compiler has no objection to this, since only pointers to memory > are passed, and the compilation and linking is error-free, but the > OP's G77 points out that the workspace variables passed to the > routines vary by type from call to call and therfore gives compiling > problems. It was usual to EQUIVALENCE arrays of the same size but different type, such that you pass an element of the appropriate type. > Another two problem areas are , where > SUBORD is defined as > REAL SUBORD(1):- > But exceeding the array size of (1), fairly common usage if you don'r > know the maximunm array size (but I checked it will be 5), gives:- Can you change to Fortran 77 style (*) assumed size dummy array? -- glen
From: Richard Maine on 13 Aug 2010 11:16
Terence <tbwright(a)cantv.net> wrote: > My compiler has no objection to this, since only pointers to memory > are passed, and the compilation and linking is error-free, but the > OP's G77 points out that the workspace variables passed to the > routines vary by type from call to call and therfore gives compiling > problems. Are these "compiling problems" errors or warnings? Showing the exact error message would be helpful. In my experience, although such code is nonstandard, the large majority of compilers will accept it with no worse than a warning. I thought that included g77, though I don't have a copy handy to check. It it generates warnings, then that is appropriate. You can either ignore them, see if there is a way to turn them off, or fix the code. Fixing the code would require more substantial surgery. > Another two problem areas are , where > SUBORD is defined as > REAL SUBORD(1):- > > But exceeding the array size of (1), fairly common usage if you don'r > know the maximunm array size... It was common practice in f66, where there were no other good alternatives short of passing the array size. However, it has never been standard conforming, even in f66. In f77, the correct solution is to use assumed size (that is dimension the dummy arrays as * instead of 1). That's exactly what assumed size is for and what it means. Do note that the messages you quoted are all warnings - not errors. One should be conscious of the diference. WIth an error, the code will not work and an object file is usually not even made. WIth a warning, an object file is produced and the code might well work correctly, as it wil in these cases. The compiler is just warning you that something is questionable. The compiler is correct here. If you really want to eliminate all warnings from f66-style code, then laudable as that might be in some sense, you are likely to have a harder job. I was assuming you just wanted to make the code work. You are lucky that the compiler only made this a warning. I have used compilers where it was an error and the code woul dnot run until it was fixed. Fortunately, the fix of changing the 1 to a * is easy here, even if you need to do it a few dozen times. If there are many more than that, it can get to be a pain and require some parsing because you don't want to blindly change every appearance in the code of (1) TO (*). > And more strangely (only the precise element number is objected to):- That's quite typical. Only when you use constant expressions can the compiler easily detect the problem at compilation time. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |