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 6 Aug 2010 03:45 In article <0fdf3e9f-79f3-40c0-a675-58d7e2010606(a)u38g2000prh.googlegroups.com>, Terence <tbwright(a)cantv.net> wrote: > > This code was written for the CDC 6400 and dated 1978 (both >specified in the text preamble) and all character references (as >assignments and usage in Format statements), was restricted to blocks >of 6, so I had to assume the 6400 had a 48-bit word, and and not some >higher number like 60 since the authors could have efficiently such a >size. It was complicated. Multiplication was 48-bit from a 60-bit word. As I recall, you could only get 6 characters in a word, though I have no idea why, as I also recall it using a 6-bit character set! I never used the system personally. > My own (fairly dedicated) experience with Fortran IV was with IBM >7040's and the like, at IBM and Shell, pretty much world-wide, and >both tended to write their code with 4-character assignments. Yup. > So, is there any semi-automatic conversion program available, or do >we dafault to hard slog? Neither. 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 .... Regards, Nick Maclaren.
From: robin on 6 Aug 2010 06:20 "Terence" <tbwright(a)cantv.net> wrote in message news:7eb9d793-e6d2-48a4-998d-9ca3d2065e9e(a)x20g2000pro.googlegroups.com... | 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. Probably was a 60-bit word. If so, integers and reals were 60 bits also. Thus, precision of integers was 59 bits, ones complement. | 2) calls to machine-dependent timing routines (possibly to allow | aborting if too much time was being taken, This should be somewhat easy to convert. | 3) output to text devices used as printers that used way above 132 | character lines. A typical line would start with 60 spaces before | starting any line of a big table of text followed by several F15.2 | values. Even longer output to a plotter. Printer widths (in general) were varied -- 120 and 132columns being common, but 160 columns were also used. | 4) use of routines with a multi-line list of parameters, but then with | internal named entry points. | 5) All output mixed selected 6-character text integers or text blanks, | all with Format statments that only used A6 formats, with possinble 2- | character literals interpersed. | 6) No opening or closing of any files (all assumied defined in JCL?) | 7) heavy use of WRITE, PRINT, PUNCH with no unit device and therefore | unusual syntax. | | Since I am still corresponding and feel I am not being very helpful, | my question is | "Is there any commercial or free Fortran compiler which will compile | this, more or less as-is (assuming removal of machine dependent | routines performed)"? The 6-character / word things tend to make it non-portable, and probably would require hand modification (if only to make the declarations of strings as double precision).
From: robin on 6 Aug 2010 06:33 "Nick Maclaren" <nmm(a)gosset.csi.cam.ac.uk> wrote in message news:i3geil$b26$1(a)gosset.csi.cam.ac.uk... | It was complicated. Multiplication was 48-bit from a 60-bit word. For the Cyber 70 series (derived from the 6000 series), the difficulty was that there were no spare instri\uction op codes. Therefore the floating-point op code was used, and when multuply was executed, it assumed integer multipy if the operands had no significant bits in the upper 12 bits, otherwise a floating-point multiply was performed. It was a nuisance should tan integer exceed 48 bits, because the floating-point multiply would produce garbage for all bits in the product. | As I recall, you could only get 6 characters in a word, If it was like the Cyber 70 series, you could get 12 characters in a word -- each one of 6 bits. However, if you wanted upper and lower case, lower-case characters required an escape code, which meant that 12 bits were used for such characters (and also for some special characters).
From: feenberg on 6 Aug 2010 07:18 On Aug 6, 1:19 am, Terence <tbwri...(a)cantv.net> wrote: > I have been trying trying to help the brother of a hopeful fortran > using sister to get her earthquake processing software converted to > useable compilable code. > (Yes, they might have picked someone else, but,,,) > I am acting as moderator of an under-used Fortran forum and trying to > do my best. > > 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. > 2) calls to machine-dependent timing routines (possibly to allow > aborting if too much time was being taken, Modern fortran has "data_and_time". > 3) output to text devices used as printers that used way above 132 > character lines. A typical line would start with 60 spaces before > starting any line of a big table of text followed by several F15.2 > values. Even longer output to a plotter. This won't bother the compiler, but may make the output hard to read. > 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. > 5) All output mixed selected 6-character text integers or text blanks, > all with Format statments that only used A6 formats, with possinble 2- > character literals interpersed. I don't see a problem there. "2hcc" will still work. > 6) No opening or closing of any files (all assumied defined in JCL?) > 7) heavy use of WRITE, PRINT, PUNCH with no unit device and therefore > unusual syntax. > That requires editing, but you should be able to make a global change. > Since I am still corresponding and feel I am not being very helpful, > my question is > "Is there any commercial or free Fortran compiler which will compile > this, more or less as-is (assuming removal of machine dependent > routines performed)"?
From: e p chandler on 6 Aug 2010 08:45
"Terence" <tbwright(a)cantv.net> wrote in message news:7eb9d793-e6d2-48a4-998d-9ca3d2065e9e(a)x20g2000pro.googlegroups.com... >I have been trying trying to help the brother of a hopeful fortran > using sister to get her earthquake processing software converted to > useable compilable code. > (Yes, they might have picked someone else, but,,,) > I am acting as moderator of an under-used Fortran forum and trying to > do my best. > > 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. Just for historical context, consider the joys of converting original "Adventure" from the PDP-10 to a more modern compiler. 7 bit ASCII packed 5 to a 36 bit word. DEC's "sixbit" was used for other things - internally. Machine specific routines and masks (octal literals) used for individual character manipulation. |