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: Richard Maine on 7 Aug 2010 17:40 robin <robin51(a)dodo.com.au> wrote: > "Richard Maine" <nospam(a)see.signature> wrote in message news:1jmsnwd.1y8u6r31f3t1oeN%nospam(a)see.signature... > | That meant you could get a spurious end of record > | by printing two colons in a row (the character code for a colon was > | binary zero), though only if the colons happened to be in the last 12 > | bits. > > And, of course, the two colons weren't printed. That happened because > CDC tried to cram 65 different characters into a 6 bit field. I wouldn't have even seen Robin's comment if someone else hadn't replied to it. I see that his accuracy is about at its usual level (which I'll leave unspecified, so he can take that as a compliment if he wants :-)). No, it had nothing to do with some imaginary character set. The colon was a perfectly fine part of the 64-character set that was used at our site. We didn't use the 63-character set, and I'm not familliar with anyone other than Robin's imagination having a 65-character one. I used CDCs as my primary machines for over a decade, so I am quite personally familliar with such things. Colons, being part of the 64-character set, printed perfectly fine... mostly. It was only when two colons in a row hit the wrong part of a word that they had odd effects. This had zero to do with some imaginary 65-character set, but everything to do with the formatted record terminator convention. See the wiki citation that LR points to. It even mentions the problem with printing colons. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Terence on 7 Aug 2010 19:50 On Aug 6, 5:45 pm, n...(a)gosset.csi.cam.ac.uk (Nick Maclaren) wrote: > .... The best solution is Python or something similar, and you > can automate enough of the changes that it will be fairly simple, > but ONLY if the program is clean. My course (given only once, but > I believe referred to a bit more) is on: > > http://www-uxsup.csx.cam.ac.uk/courses/OldFortran/ > > I have done such conversions many times and in several ways, and > it always ends up being easier than it looks. For Fortran. Just > try it for C, especially C polluted by preprocessor abuses .... > 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.
From: Terence on 7 Aug 2010 19:54 On Aug 6, 9:18 pm, feenberg <feenb...(a)gmail.com> wrote: > > The problems I saw were > > 1) The program was written for a CDC computer that used integer*4 > > words of at least 48 bits in width, because all text was stored in 2-D > > arrays of 6 characters, initialised and manipulated as integers and > > written out using A6 fomats. > > Convert the declaration for the character variables to double > precision, which will allow up to 8 characters. The A6 format will > print only 6, > so the 2 blanks will not show up in the output. > Now that might work; I must think about the implications elsewhere. > > > 4) use of routines with a multi-line list of parameters, but then with > > internal named entry points. > > Entry statements are still supported in most compilers and long > lists of parameters shouldn't be a problem. H'm my compiler objects to "ENTRY" within the body of the subroutine.
From: Terence on 7 Aug 2010 19:56 On Aug 8, 7:18 am, LR <lr...(a)superlink.net> wrote: > robin wrote: > > And, of course, the two colons weren't printed. That happened because > > CDC tried to cram 65 different characters into a 6 bit field. > > Wouldn't that depend on if you were using Display 63 or Display 64, > since there's no graphic associated with octal 00 in 63?http://en.wikipedia.org/wiki/CDC_display_code > > LR And Oh, YES; I forgot to say the output formats used some Octal values formats which surprised me - probable part of the machine-dependent coding and alls.
From: Richard Maine on 7 Aug 2010 20:24
Terence <tbwright(a)cantv.net> wrote: > H'm my compiler objects to "ENTRY" within the body of the subroutine. Lacking any further data, it is hard to evaluate that problem. ENTRY has been part of the standard since f77. By definition, you will not find a full language f77 or later compiler that does not support it. I believe I recall that you once were using an f77 subset compiler (one of the very few ever to exist) at one time, so that one might well have not supported ENTRY. Many, but not all, f66 compilers supported nonstandard forms of ENTRY, though there were variations in syntax. Within the body of a subroutine (or function) is the only place where ENTRY has ever been allowed or makes sense, so I'm not sure what that qualification is supposed to imply. I am left with pretty much the same advice regularly given to posters here. If you want help, post the exact code and exact resulting error message. A description of what you think the problem was isn't worth much compared to actually seeing the problem. In this case, the odds are low that the problem is correctly described as objecting to ENTRY within the body of a subroutine unless you happen to be using an f77 subset or pre-f77 compiler. Something like having the syntax of ENTRY wrong might be plausible, but I have no data to evaluate. Oh, or a last-minute thought. An error from trying to put an ENTRY inside of an executable construct or DO loop is very plausible. There is a restriction against that and I suppose I could see misinterpreting or misparaphrasing the error message you would probably get from trying to do so. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain |