Seeking to thrive in a rapidly paced marketplace, the makers of most technologically based products continually bring forth not only innovations that differentiate their products from those of others, but also improvements that offer new features or better performance. For computer systems, we should expect evolution in implementations and perhaps extensions of architectures. In practice, the dividing line between changes at the levels of architecture and implementation can blur. Moreover, certain functions and features can be implemented in hardware, in firmware, or in software. Indeed, computer manufacturers sometimes extend a computer architecture in ways that call into question the rather strict definition of architecture in this book. Several successful computer architectures have persisted for more than two decades. During such lengthy intervals, many temptations and perhaps some genuine opportunities to modify the architecture will occur. Which is the best use of available area on the chip: to support additional instructions, to achieve faster instruction execution, or to provide larger on-chip instruction and data caches? New instructions can be added where the original architecture had reserved unused opcodes and function codes. Can and should any new instructions be somehow supported retrospectively on older systems through software emulation? Different companies at different times have chosen a variety of responses to such concerns. Any proposed change ought to be weighed against the impact on existing customers and developers of software applications, who are accustomed to the original architectural features. Faced with architectural extensions, a software application developer would generally have to choose among several strategies:
Customers often prefer the latter two options, so long as the supplier does not raise prices appreciably. The Itanium architecture specification explicitly requires that software emulation in the kernel of an operating system be able to complete any valid instruction that cannot be executed wholly by the hardware. If new instructions are added to the architecture, the system software must be revised to enable systems based on older hardware implementations to remain in architectural conformance. This approach has the advantage of requiring minimal action on the part of either customers (just the system software upgrade) or third-party software producers (just the effort of incorporating the new instructions). In this chapter, we shall discuss the various implementations that may occur within the Itanium architecture over its life cycle (Section 1.6). Differences between the first two marketed Itanium processors, as well as a few historical examples involving other architectures, will illustrate the general principles. We eschew any temptation to predict specific future developments or product features. |