- On Architecture: Goodness of Fit
- Inventing Fortran
- An "ideal" architecture?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Inventing Fortran
First, John observed that all the original reasons for creating Fortran were no longer valid. Fortran wasn't the first high-order programming language (although it was certainly the most influential and most widely used). He created it to prove that you could write efficient compiled programs and make more economical use of the computational power at hand. As to the first point, the question of whether compiled programs are more efficient than hand-coded machine code is essentially moot. Contemporary compiler technology permits optimizations in the large that in many cases an individual can't see. Furthermore, the complexity of most contemporary systems is so overwhelming that any incremental advantage you gain by hand-coding is lost in the noise (although hand-tuning parts of critical algorithms is still common practice in some time-critical systems).
Also, the economics of computing have completely reversed since the 1950s. Then, the annual cost of renting a single machine was far greater than the annual burdened cost of a team of programmers. So, to keep a machine busy, the team had to be able to push more complex applications to it quickly. Today, the burdened cost of a single programmer is far greater than the cost of several reasonably powerful computers. Furthermore, for most interesting systems, the inherent complexity and scale are such that even just developing and deploying that software is incredibly costly.
Second, John reported that when the team began defining the Fortran language and compiler, they had to invent virtually everything. Little precedence existed to guide them regarding the language's syntax or features (Fortran I didn't even have subroutines), and there were certainly no good examples of other compilers from which they could borrow. As a result, the team simply tried things, then adopted them if they worked and rejected them if they didn't or were too complex. The fact that IBM management let John's team work in relative isolation and with minimal management intervention gave them an ideal environment in which to innovate. At the same time, it was impossible to predict the end of this effort, which slipped from year to year: the team produced a preliminary Fortran I report in 1954 but didn't release a relatively complete compiler until 1957.
Third, John noted that the structure of the original Fortran compiler divided nicely into a handful of phases, encompassing the typical ones we know today of parsing, semantic analysis, optimization, register allocation, and target code generation. To some degree, this division of labor was a result of the structure and skill set of John's team, but for all their experimentation and false starts, these phases reflected the natural flow in transforming source code to machine language.