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 6 Aug 2010 11:58 Nick Maclaren <nmm(a)gosset.csi.cam.ac.uk> wrote: [about oldish CDC machines like the 6400] > 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. I used 10 characters per word all the time, as did oodles of code I had to deal with. Yes, arithmetic operations on integers greater than 48 bits had odd effects, but you didn't do such multiplications on Hollerith data, so it worked fine. Well, there was one oddity about character data and the last 12 bits. The end of a formatted data record was indicated by a word with binary zeros in the last 12 bits. (The 6-bit character set did not include anything like control characters and formatted data did not use record-length fields). 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. This was independent of Fortran Hollerith; any way of printing colons at the wrong columns of a line would trigger it. It made a mess of codes where people used a long row of colons in a comment as a visual separator. It also wouldn't do well with f90, although most of my days with CDC machines were before even f77. We didn't see an f77 compiler until sometime in the early '80s, and the last of our CDC machines left in 1984. An interesting thing about integer arithmetic operations was that... there were none - at least none with their own dedicated opcodes. You just used the same opcodes as for floating point, and the hardware special-cased operands with the 12 high order bits all 0 or all 1. It seemed like the machine was designed to crunch floating point numbers, with integers being a special case. I spent many hours of my youth converting code to and from CDC machines, pretty much all of it done manually. No I don't know of any nice automated tools for the purpose. Some of the codes were full of complicating factors like equivalences that depended on things like there being 10 characters per word or on more subtle matters. These wasted hours of my youth contributed substantially to my subsequent interest in portability issues. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: Nick Maclaren on 6 Aug 2010 13:00 In article <1jmsnwd.1y8u6r31f3t1oeN%nospam(a)see.signature>, Richard Maine <nospam(a)see.signature> wrote: > >[about oldish CDC machines like the 6400] >> 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. > >I used 10 characters per word all the time, as did oodles of code I had >to deal with. Yes, arithmetic operations on integers greater than 48 >bits had odd effects, but you didn't do such multiplications on >Hollerith data, so it worked fine. Thanks for the correction. >I spent many hours of my youth converting code to and from CDC machines, >pretty much all of it done manually. No I don't know of any nice >automated tools for the purpose. Some of the codes were full of >complicating factors like equivalences that depended on things like >there being 10 characters per word or on more subtle matters. These >wasted hours of my youth contributed substantially to my subsequent >interest in portability issues. I did a little, non-manually - but I did have access to a GOOD, programmable editor. Nowadays, as I said, I use Python. However, as you know, that will work only for relatively clean code. For example, if the variables used for characters are all distinct, they can all be defined as CHARACTER(LEN=10), and it doesn't require much of a parser to detect almost all of them. But, if some genius used the same integer variable for integers, characters and as an assigned GOTO label in the same procedure, a complete rewrite is indicated .... Regards, Nick Maclaren.
From: Dr Ivan D. Reid on 6 Aug 2010 16:31 On Fri, 6 Aug 2010 08:58:05 -0700, Richard Maine <nospam(a)see.signature> wrote in <1jmsnwd.1y8u6r31f3t1oeN%nospam(a)see.signature>: > Well, there was one oddity about character data and the last 12 bits. > The end of a formatted data record was indicated by a word with binary > zeros in the last 12 bits. (The 6-bit character set did not include > anything like control characters and formatted data did not use > record-length fields). 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. This was another thing I had to find a workaround for in my SC/MP cross-assembler to produce 8-bit paper tapes. I had to set the 4 high bits of the 12-bit bytes to 1 (they were ignored on output, just the lower 8 bits being punched) otherwise any zero byte would lead to all 12 bits being zero and the output would stop. -- Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration, Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN KotPT -- "for stupidity above and beyond the call of duty".
From: robin on 7 Aug 2010 06:43 "Richard Maine" <nospam(a)see.signature> wrote in message news:1jmsnwd.1y8u6r31f3t1oeN%nospam(a)see.signature... | Nick Maclaren <nmm(a)gosset.csi.cam.ac.uk> wrote: | [about oldish CDC machines like the 6400] | > 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. | | I used 10 characters per word all the time, as did oodles of code I had | to deal with. Yes, arithmetic operations on integers greater than 48 | bits had odd effects, but you didn't do such multiplications on | Hollerith data, so it worked fine. | | Well, there was one oddity about character data and the last 12 bits. | The end of a formatted data record was indicated by a word with binary | zeros in the last 12 bits. (The 6-bit character set did not include | anything like control characters and formatted data did not use | record-length fields). 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. It took CDC a few decades to work out that 8-bit bytes were needed for a character set and for communication with other computers. The NOS OS that they produced subsequently was a dream, and it used 8-bit characters. | This was independent of Fortran Hollerith; any way of printing | colons at the wrong columns of a line would trigger it. It made a mess | of codes where people used a long row of colons in a comment as a visual | separator. It also wouldn't do well with f90, although most of my days | with CDC machines were before even f77. We didn't see an f77 compiler | until sometime in the early '80s, and the last of our CDC machines left | in 1984. | | An interesting thing about integer arithmetic operations was that... | there were none - at least none with their own dedicated opcodes. You | just used the same opcodes as for floating point, and the hardware | special-cased operands with the 12 high order bits all 0 or all 1. It | seemed like the machine was designed to crunch floating point numbers, | with integers being a special case. That's not correct. It was only true of "integer" multiply, which was tacked on the back of the floating-popint multiply instruction, and used the same op-code [as I already posted].
From: LR on 7 Aug 2010 17:18
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 |