Prev: Problem with automatic reallocation of allocatable scalar on assignment
Next: a wiki entry for gfortran
From: glen herrmannsfeldt on 8 Aug 2010 02:37 Terence <tbwright(a)cantv.net> wrote: (snip) > I see a simple way to insert an integer variable (values 1,2,3) in > the parameter list for the three uses of the routine which has > multiple entry points (one to initialise, one to run and one to output > all final matrices). These three calls will now first set this value > to 1,2 or 3 and call the routine, where the first line will branch to > the appropriate code section. If you don't, the compiler will. At least that is what it looks like gfortran does with ENTRY. Little routines for each entry point, then call the big routine will all the possible arguments. -- glen
From: Nick Maclaren on 8 Aug 2010 03:55 In article <a3b5decf-b61a-40da-a1ef-33c6e334b807(a)w15g2000pro.googlegroups.com>, Terence <tbwright(a)cantv.net> wrote: > >I checked Nick's web-site and advice there, but this code is way too >far dedicated to the CDC 6400 to be able to use any parsing system to >modify it. It is a form of Fortran IV so in theory rewriting it to F77 >as a first step does semm indicated. The alorithms used are clear and >could be followed by using a huge print-out of the 3000 lines and >writing code while looking sideways, and with cut-and paste tricks >(with two half screens) to help with the typing. > >I am a great user of parsing methods, which I have ised for my own >hand-built commercial compilers that solve some any-language >omunication problems, so I have used parsing a lot since 1961, so my >believe that parsing won't help is experience-based. A pity about that. I wasn't meaning to deprecate your experience, but other people's ideas often help. I would be surprised if you couldn't fix up the syntax, but that's often only 10% of the job in the sort of code you are describing. The way that I have often done that is to use automatic parsing to fix up the simplest issues, and then got in and manually edited the rest - more-or-less as you say, but using one screen rather than two. That's obviously just a matter of personal preference. 3,000 lines is tedious, but not too foul a job. I don't know of a better method for such code. Regards, Nick Maclaren.
From: Terence on 8 Aug 2010 04:08 Well, I even have a program I wrote, to parse Fortran loaded with Hollerith assiments and format statements, that looks for DO loops that terminate on an assignments, and so adds the appropriate later CONTINUE statement, moving the label (after checking this is actually logically correct), and also nests levels, producing a very readable output new source, and as an option re-writing everything with sequential labels (in separate sequences for Formats and executable statements). The "gotcha" is that it (I) didn't expect hollerith assigments to variables that were not some multiple of 4 bytes; and this program is so chock-full of 6-character integer arrays of messages. The use of hollerith in format statements is just re-written as literals, and control bytes concatenated if possible. As for the program under conversion, I mentioned all the open statements needed, and some care over 20 scratch files used. At least what I have now compiles without detected errors (which is what the old trusty compiler is VERY good at, whatever unrecognised faults it might have). There just aren't any "simple" issues in this. Interesting how similar is the problem to my lng conversion of the BMD programs last year, rescued as source from DEC historic CDC files...
From: Louis Krupp on 8 Aug 2010 04:50 On 8/8/2010 12:23 AM, Terence wrote: > One more problematic item of code. > The program assigns variables in a very-frequently-met trick of the > old days, to a common block of memory defined as > COMMON X(1) > > Then a routine is called ADJUST, which is first called with > IM=0. > This use then sets LRUN to the value of LCM and dfurthe use takes a > new branch where memory is divided up fbeginnig the first defined > address NUMBER. > 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". > > Once I get this understood I code the routine properly and can begin > tesring. > > > SUBROUTINE > ADJUST(LRUN,LCM,IFL,IM) ADJUST 2 > > IFL=0 > ADJUST 3 > IF (IM) > 10,10,20 ADJUST 4 > 10 > LCM=120000B > ADJUST 5 > RETURN > None of that is readable with my newsreader (Thunderbird). I take it that the "ADJUST n" bits are sequence numbers in columns 73-80. If you could remove those and repost, it will look a lot better. Louis
From: Louis Krupp on 8 Aug 2010 04:53
On 8/7/2010 11:05 PM, Terence wrote: > OK. > Now I've got down to a compilable version, with the three ENTRY > points commented out. > > I've asked permission to post the (user-puchased and copyright) code, > still wainting for that. > > I see a simple way to insert an integer variable (values 1,2,3) in > the parameter list for the three uses of the routine which has > multiple entry points (one to initialise, one to run and one to output > all final matrices). These three calls will now first set this value > to 1,2 or 3 and call the routine, where the first line will branch to > the appropriate code section. > > I have more or less reworked every character-containing variable to > be strings of 6,12,18 or 60 characters and re-worked the reporting > format statements. > > I still have to open and control 1 to 20 work files ("Tapes") which > shuld be straight-forward. > > Ho-hum.. At least I'm not being a coauch potato today. > > My compiler for this job is MS 3.31 of August 1985. Checked manual > index; nor reference to ENTRY, which I have used somewhere else in the > past; bit surprised! Not in Burroughs, or IBM Fortran manuals of same > date that I have, either. > > Then if and when this works I will go to DVF V6.6c as last check, > then try real life data (which I have). If DVF V6.6c implements ENTRY, could you use it instead of MS 3.31 now? Then you could leave the ENTRY part alone. Louis |