Why these original FORTRAN quirks?
in [Fortran]
|
From: David Flower on 14 Oct 2006 10:09 On Oct 14, 9:02 am, Brooks Moses <bmoses-nos...(a)cits1.stanford.edu> wrote: > Rostyslaw J. Lewyckyj wrote: > > Andrew Swallow wrote: > >>Columns 73 to 80 were for card sorting. BASIC is the language with > >>the label on every line. Putting a label on every line in Fortran > >>uses up the symbol table and switches the optimiser off. > > > Really?Somewhere online is a scanned version of the October 15, 1956 IBM manual > entitled "Fortran Automatic Coding System for the IBM 704", which was > pretty much the original public document describing the language. > > On page 44 [1], there is a list of the various symbol tables that the > Fortran compiler uses -- there are quite a lot, so "symbol table" is > misleading -- and the first entry is "(TEIFNO Table). The number of > Fortran statements which have statement numbers must not exceed 1500." > > As for switching off the optimiser, that presumably was a later version, > as this one is before the compiler was fancy enough that one could > switch it on. :) > > - Brooks > > [1] Which in the scan is unfortunately repeated in place of page 42. > > -- > The "bmoses-nospam" address is valid; no unmunging needed. For those of you who never encountered a punch-card in anger, it was possible to electro-mechanically sort a deck that had been accidently dropped - provided that columns 72-80 were numbered in order Dave Flower
From: Gene Wirchenko on 14 Oct 2006 22:03 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: [snip] >Stories are that the first Fortran compiler had a good optimizer. >It was considered necessary to compete with assembler programmers >in code speed. Optimizers I know of know which labels are used and So I understand. >which aren't, but it might be that not all do that. I assume that it was this (or something similar): Limited storage was an issue. There could be backwards references, so the compiler could not know that a label would not be used until it had read the whole source or at least a whole module. Either that, or another pass would be needed. Due to the limited storage, that might not have been possible either. Sincerely, Gene Wirchenko Computerese Irregular Verb Conjugation: I have preferences. You have biases. He/She has prejudices.
From: glen herrmannsfeldt on 15 Oct 2006 01:10 Gene Wirchenko wrote: (snip on historical Fortran and optimizing compilers) > Limited storage was an issue. There could be backwards > references, so the compiler could not know that a label would not be > used until it had read the whole source or at least a whole module. > Either that, or another pass would be needed. Due to the limited > storage, that might not have been possible either. With limited storage, it is usually required to keep some data on external storage, tape or drum on early machines, disk on later machines. Also, the restrictions on DO loops, even with extended range of a DO loop, allow for some optimization even with statement labels. -- glen
From: Lynn McGuire on 16 Oct 2006 12:53 >> On page 44 [1], there is a list of the various symbol tables that the >> Fortran compiler uses -- there are quite a lot, so "symbol table" is >> misleading -- and the first entry is "(TEIFNO Table). The number of >> Fortran statements which have statement numbers must not exceed 1500." >For those of you who never encountered a punch-card in anger, it was >possible to electro-mechanically sort a deck that had been accidently >dropped - provided that columns 72-80 were numbered in order That is columns 73-80. Lynn
From: James Parsly on 16 Oct 2006 14:09
When I was in high school, back in 1975, we had an IBM 1620 with a Fortran II compiler. It had 20K digits of memory and no disk or tape of any kind. Our procedure for compiling was as follows: 1. Read pre-compiler deck using card read. We would then all line up to run our card decks through the card reader. This part only checked for obvious syntax errors, a lot of which resulted from miscounted hollerith strings in FORMAT statements. 2. We would then load up the actual compiler, and read our decks through it. I can't remember if we had to read the decks twice, although that seems reasonable. I do remember that you'd get to a point where the card reader would seem to be reading the source deck one card at a time, at which it would punch several cards of "object deck" 3. Finally we would load the "fixed subroutine" deck, which I suppose was the "run time library". It used up the first 6000 or so digits of memory. You would then read your "object deck" back in. Finally you would hit a button that allowed you to enter a command that told the system where to start running your code. Seems like a huge pain-in-the-butt looking back, but at the time we all thought it was truly cool. Plus the room where the computer was located was the only classroom at the school that had air conditioning. "glen herrmannsfeldt" <gah(a)ugcs.caltech.edu> wrote in message news:a8OdnbyxQNISX6zYnZ2dnUVZ_tSdnZ2d(a)comcast.com... > Gene Wirchenko wrote: > > (snip on historical Fortran and optimizing compilers) > >> Limited storage was an issue. There could be backwards >> references, so the compiler could not know that a label would not be >> used until it had read the whole source or at least a whole module. >> Either that, or another pass would be needed. Due to the limited >> storage, that might not have been possible either. > > With limited storage, it is usually required to keep some data on > external storage, tape or drum on early machines, disk on later > machines. > > Also, the restrictions on DO loops, even with extended range of > a DO loop, allow for some optimization even with statement labels. > > -- glen > |