• Please review our updated Terms and Rules here

Fortran Coding Sheet

Mike_Z

Veteran Member
Joined
Dec 1, 2013
Messages
1,713
Location
Near Milwaukee Wisconsin
I have been relearning Fortran IV and have advanced to the point where I want to format the output to look nice. I have forgotten how much of a pain the FORMAT statement is. You have to count every space and character to use the Hollerith stuff. I've been trying to use graph paper, but..... I remember using coding sheets in the past (long past), something like thisFortranCodingSheet.JPG
I've been looking for a nice high definition copy on the internet, but have not found one. Looked at bitsavers, but again have not found anything. Just wondering if anyone has one or know where a good blank form is? Thanks, Mike
 
Last edited:
Thanks for the response. I too must have burnt through a mess of these sheets in the past. Last night I was on a mission to find some of that old stuff. I could have sworn that I still had some old card decks and maybe some of these pads, but they are not to be found. Krebizfan, I want to take your sheet to a local printer and have them print up a bunch of these on some larger paper, maybe 11 x 16. That will help me with seeing it better. I appreciate the help. By the way my latest FORTRAN program calculates various mile per hour valves for various engine speeds using the 4 different rear axle ratios available for my 1937 Ford. I hope to start work on rebuilding (seems car people use rebuild, whereas computer use restore) the rear axle this winter. Anyway I'm having fun writing FORTRAN programs and becoming familiar with all the error codes again. Mike
 
I started with a dialect called (IIRC) USA BASIC FORTRAN. No frills FORTRAN; probably the same dialect that you would get with the entry-level PDP-8 systems. Only one type of IF (3-way arithmetic branch), mixed-mode expressions forbidden, etc. I doubt that someone from that time would recognize modern Fortran dialects as FORTRAN.
 
Hey Mike,

I thought about you on the way back from my business trip today!

I saw a beautiful Model 'T' on a trailer on the motorway. It must have been going to a show for the weekend, as I saw a few other vintage cars on trailers heading in the same direction.

Dave
 
Chuck, If I remember correctly the DEC FORTRAN II had only one IF statement. The FORTRAN IV that I'm using on the PDP8e has both the logical and the arithmetic IF statements. The FORTRAN that I used years ago on the Burroughs 5500 was also FORTRAN IV. Makes programming a little easier.
Dave, the driving season is rapidly coming to an end, although I drive mine through the winter, most guys are putting their cars away. The Model T drives through the snow really nice. It stops about as good and any other car. Not having a heater or windshield wipers makes driving in cold weather a real experience. Mike
 
Yes, that's very typical of the FORTRAN II varieties. The one thing you have to marvel at is the absolute number of varieties of FORTRAN that vendors implemented before F77. I think that I recall that 7090 FMS had some odd column 1 conventions. A "B" in column one signified a boolean operation (+ = OR,etc.), whereas an I (IIRC) signified complex math.

As a compiler maintainer, one thing that was a headache was detecting possible conflicts in EQUIVALENCE/COMMON statements. How I hated those statements!

One thing that I liked about 1620 FORTRAN IID was the ability to specify the precision of the internal representation with a control statement (FANDK); floating-point up to 28 digits and integers up to 10.
 
Last edited:
I knew Steve, but I was working in Special Systems at the time. Much of our compiler work and maintenance was done separately, as we used our own operating systems. So if CPD made a change, it had to be vetted by SSD before it could be incorporated into our software. It was a very complicated picture. For example, we maintained contact with Don Nelson on COBOL matters, but had our own version of the compiler and runtime. Similarly, CPD was almost totally oblivious to what was going on in SSD--and very few people were privy to what was going on in ROVER. The reason was quite simple--most of the CPD people lacked the necessary security clearances to work on SSD projects.

The reason for this was mostly that SSD was all government contracts and so had to stick to the letter of the contract terms. Thankfully, by the mid- to late-1970s, much of that nonsense went away. ROVER endured probably to the bitter end, for all I know.

Around 1974, I moved from the umbrella of SSD to STAR. Left in 1977 to explore the wonderful world of microprocessors.

Richard Frank and Paul McQuesten left CDC's CPD to start up SORCIM. I don't know if Paul left his signature in the Osborne 1 CP/M CBIOS, but that's who wrote it.

Sometimes I wonder whatever became of the hundreds of thousands of man-hours invested in the thousands of reels of tape in SSD. Since much of the stuff was classified, probably incinerated.
 
Last edited:
I have the source of Fortran IV for the CDC 6000/CYBER series. This is some very clever bit of software. The optimization is remarkably good even for today. It fully utilized all the parallel features of the CPU. If I needed to do something more complex in Compass CPU assembly I often coded the algorithm in Fortran and used the Fortan IV compiler to spit out Compass source to get a baseline to start from.
The subsequent Fortran V compiler was slower to compile and generated inferior code.
 
Which compiler? RUN or FTN? FTN was the optimizing compiler; RUN was the older compiler with ties to Chippewa.

At CDC SVLOPS, a course on CPU instruction scheduling was pretty much mandatory for the programmers in my unit. Conducted by Jack Neuhaus, IIRC. Scheduling of 6600/74 instructions was a very big deal--squeezing every last minor cycle was very important. There was a bit of a sense of triumph when you could code a loop (where scheduling only really mattered) where there were no idle cycles. I could probably write a storage-move loop with no idle cycles from memory today.

Seems strange to be discussing things from 50 years ago...
 
My recollection is that it's COMPASS with some FORTRAN. I recall the monstrosity that was a state machine to figure out the relationship of COMMON/EQUIVALENCE was FORTRAN with a ton of assigned GOTOs. Gave me a headache figuring it out, mostly due to an "extension/feature" in the language that didn't require a list of possible targets in the GOTO statement, so it wasn't obvious from the code where a GOTO statement was going. i.e.

ASSIGN 100 TO J
....
ASSIGN 200 TO J
...
ASSIGN 666 TO J
....
GOTO J

Mind you, this was a routine without a single comment. Now imagine a routine with nothing but assignment statements and assigned GOTOs.

One of the worst ideas that FORTRAN language designers ever had. So bad, that it was declared obsolescent in F77, and, I believe, completely deprecated in F90. (It's hard to believe that X3J3 started on F90 40 years ago--I was an alternate in the Vector Extensions working group--therein lies a particularly ugly story).

The notion of "don't touch it--you might break it" code wasn't as rare as you might think. I remember tacking performance improvements in STAR IMPL (a dialect of LRLTRAN) and talking to the guy in charge of maintenance, asking about one routine or the other. Got lots of "I don't know how that works, so I don't touch the code" responses.
 
Last edited:
Back
Top