Prev: Problem with automatic reallocation of allocatable scalar on assignment
Next: a wiki entry for gfortran
From: robin on 7 Aug 2010 22:30 "Richard Maine" <nospam(a)see.signature> wrote in message news:1jmuykj.x0fe2h14oke2iN%nospam(a)see.signature... | 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 character set had 64 characters, . CDC then tried to use one of those values (actually 12 bits occurring at the end of a word) to signifiy end-of-record. In other words, 65 functions associated with a 6-bit character. That's why it came to grief. | 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. We had two such machines for about 15 years, so I am perfectly familiar with the operation of the haredware. More tham most, because I wrote a compiler for those two maachines. And as for your being "personally familiar with such things", you got it wrong (yet again) about "arithmetic operations on integers greater than 48 bits had odd effects", because integer operations such as addition and subtraction involved all 60 bits; it was only integer multiplication that was restricted to 48-bit operands. | Colons, being part of the 64-character set, | printed perfectly fine... mostly. It stuffed things up, to put it mildly. | 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, which amounts to 65 functions associated with 6 bit characters, whch is what I say they tried to do, and it just didn't work.
From: robin on 7 Aug 2010 22:41 "LR" <lruss(a)superlink.net> wrote in message news:4c5dcd9a$0$2374$cc2e38e6(a)news.uslec.net... | 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? CDC offered several character sets, none of which was entirely satisfactory, as the machine that we had replaced one that had a 64 character set.
From: Richard Maine on 8 Aug 2010 00:34 robin <robin51(a)dodo.com.au> wrote: > | > CDC tried to cram 65 different characters into a 6 bit field. .... > which amounts to 65 functions associated with 6 bit characters, > whch is what I say they tried to do No, you said 65 characters, as quoted above. characters /= functions Record termination does not necessarily involve either characters or functions. -- 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 8 Aug 2010 01:05 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).
From: Terence on 8 Aug 2010 02:23
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 |