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: Dr Ivan D. Reid on 8 Aug 2010 11:45 On Sun, 8 Aug 2010 21:47:15 +1000, robin <robin51(a)dodo.com.au> wrote in <4c5e9948$0$34572$c30e37c6(a)exi-reader.telstra.net>: > "Dr Ivan D. Reid" <Ivan.Reid(a)ivan.fsnet.co.uk> wrote in message news:slrni5nem7.1uk.Ivan.Reid(a)smtp.orangehome.co.uk... >| My experience with a Cyber in 1978 was that it had a 60-bit word >| but integer multiply/divide only worked up to 48 bits. To shift a 48-bit >| integer to 60 bits to add a 5th 12-bit byte I had to use successive adds >| (i=i+i). > There was a shift instruction that would have done the job in one step. In FORTRAN? -- 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 8 Aug 2010 11:57 "Nick Maclaren" <nmm(a)gosset.csi.cam.ac.uk> wrote in message news:i3m9g1$bba$1(a)gosset.csi.cam.ac.uk... | In article <i3m8ad$99i$1(a)news.eternal-september.org>, | mecej4 <mecej4.nyetspam(a)opFeramail.com> wrote: | > | >This is speculation on my part, but this may throw some light on why two | >colons had quite a different effect than the once-repeated effect of a | >single colon. | | I would trust what Richard Maine says, and ignore anything that | conflicts with it. Certainly in this context. Maine has been wrong on both matters that he contributed :- 1. He said that integer operations were produced by floating-point op codes, and as a consequence, that results were 48 bits. (untrue; instructions for 60-bit integer addition and subtraction had separate op-codes from the floating-point equivalents); 2. that of the 64-character set, CDC used one character value (the double colon) to signify end-of-line, which created a conflict because there were then effectively 65 different purposes obtained from those 6 bits. And no, the colon wasn't an escape character. Had it been an escape character, there would have been two escape codes -- the double zero to signify end-of-line, and zero with a non-zero to indicate a colon. That wasn't done. Instead, a double colon in the 9th and 10th character positions (modulo 10) produced a line feed, and the double colon was not printed.
From: robin on 8 Aug 2010 12:21 "Dr Ivan D. Reid" <Ivan.Reid(a)ivan.fsnet.co.uk> wrote in message news:slrni5tk95.94f.Ivan.Reid(a)smtp.orangehome.co.uk... | On Sun, 8 Aug 2010 21:47:15 +1000, robin <robin51(a)dodo.com.au> | wrote in <4c5e9948$0$34572$c30e37c6(a)exi-reader.telstra.net>: > "Dr Ivan | D. Reid" <Ivan.Reid(a)ivan.fsnet.co.uk> wrote in message | news:slrni5nem7.1uk.Ivan.Reid(a)smtp.orangehome.co.uk... | | >| My experience with a Cyber in 1978 was that it had a 60-bit word | >| but integer multiply/divide only worked up to 48 bits. To shift a 48-bit | >| integer to 60 bits to add a 5th 12-bit byte I had to use successive adds | >| (i=i+i). | | > There was a shift instruction that would have done the job in one step. | | In FORTRAN? ISHFT in FORTRAN, and a shift instruction in machine code.
From: Ron Shepard on 8 Aug 2010 12:31 In article <4c5ed409$0$34573$c30e37c6(a)exi-reader.telstra.net>, "robin" <robin51(a)dodo.com.au> wrote: > Maine has been wrong on both matters that he contributed :- > 1. He said that integer operations were produced by floating-point op codes, > and as a consequence, that results were 48 bits. > (untrue; instructions for 60-bit integer addition and subtraction had > separate op-codes from the floating-point equivalents); > 2. that of the 64-character set, CDC used one character value (the double > colon) > to signify end-of-line, which created a conflict because there were > then effectively 65 different purposes obtained from those 6 bits. I'm not particularly interested in this discussion of character sets on ancient machines that I never used, but I have to say that the above two sentences are not accurate representations of posts to this thread for the past few days. You have to wonder why this incorrect summary would be posted when it is so easy to read back through the threads to see what Richard Maine actually said. $.02 -Ron Shepard
From: robin on 8 Aug 2010 12:38
"Richard Maine" <nospam(a)see.signature> wrote in message news:1jmw8bk.11rn30t1asz51cN%nospam(a)see.signature... | CDC machines of that era did not have bytes. At all. | ... | If this represents something about memory (as is plausible - the CM in | LCM might stand for core memory), the units are probably 60-bit words. | That's the units that memory was measured in. As noted previously, | characters were 6 bits, but the machine could not physically address | individual characters The CDC Cyber 70 series could. They had a character unit, and when supplied with a length and an offset, character instructions could move N characters starting anywhere in a word to a destination starting anywhere else in a word. There were two formats, one for short strings and another for long strings. The only machine in the series that could not be fitted with the character unit was the largest/fastest in the range -- sort of a downwards compatible instruction set. On the slowest machine in the range, the character unit was compulsory; on the middle machine(s) it was optional extra, and on the fastest, it was omitted (and not available). | and there wasn't really a term used to refer to | the storage used by a character. On occasion, you might here someone | talking about the machines having a 6-bit byte, but I don't consider | that accurate; they just didn't have bytes of any size - only words. They did, as I described above. And with or without the character unit, characters could still be still manipulated by using the integer, mask, and shifting instructions. |