| Unlike the [[https://users.ece.cmu.edu/~jhoe/doku/doku.php?id=advice_column#what_is_the_study_of_computer_architecture |above]], here, we are talking about the architecture of a programmable system where some notion of "hardware/software interface" makes sense. | Unlike the [[https://users.ece.cmu.edu/~jhoe/doku/doku.php?id=advice_column#what_is_the_study_of_computer_architecture |above]], here, we are talking about the architecture of a programmable system where some notion of "hardware/software interface" makes sense. |
| The 1964 IBM System/360 paper by Amdahl, Blaauw and Brooks defines “architecture” as a description of “the attributes of a system as seen by the programmer, i.e., the conceptual structure and functional behavior, as distinct from the organization of the data flow and controls, the logical design, and the physical implementation.” A later book by Blaauw and Brooks entitled “Computer Architecture” gives a conforming definition, “the minimal set of properties that determine what programs will run and what result they will produce.” In both writings, it is elaborated that a central tenet of their definition is that performance and time should not be attributes/properties made explicit to the programmer by an architecture. They also make clear that an architecture could include specifications of (1) when, while still valid, programmer-visible behaviors are allowed to be undefined, and (2) when a program is invalid (such that the architecture does not apply at all), neither of which is the same as the concept of “exceptions”. | The 1964 IBM System/360 paper by Amdahl, Blaauw and Brooks defines “architecture” as a description of “the attributes of a system as seen by the programmer, i.e., the conceptual structure and functional behavior, as distinct from the organization of the data flow and controls, the logical design, and the physical implementation.” A later book by Blaauw and Brooks entitled “Computer Architecture” gives a conforming definition, “the minimal set of properties that determine what programs will run and what result they will produce.” In both writings, it is elaborated that a central tenet of their definition is that performance and time should not be attributes/properties made explicit to the programmer by an architecture. They also make clear that an architecture could include specifications of (1) when, while still valid, programmer-visible behaviors are allowed to be undefined, and (2) when a program is invalid (such that the architecture does not apply at all), neither of which is the same as the well-defined concept of “exceptions”. |
| The above is probably the most commonly adopted general definition. This definition was motivated by the desire for binary compatibility across System/360 models. It is not universal or even most appropriate in all contexts. A very practical and precise definition of “architecture” could be simply “whatever the architecture specification you are reading says”. Not all architecture specifications stay within the spirit of the common definition. | The above is probably the most commonly adopted general definition. This definition was motivated by the desire for binary compatibility across System/360 models. It is not universal or even most appropriate in all contexts. A very practical and precise definition of “architecture” could be simply “whatever the architecture specification you are reading says”. Not all architecture specifications stay within the spirit of the common definition. |
