Chapter 13. Variations Among Implementations

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:

  • IgnoreSymbolthe new instructions, thereby depriving new hardware customers of optimal performance.

  • Urge customers to upgrade their hardware, either overtly or by defining a new or enhanced software product having higher minimum hardware requirements, but perhaps lose revenue from customers who do not adopt the new hardware.

  • Produce and maintain dual versions of the traditional software product through "conditional compilation," thereby increasing overhead, distribution costs, support costs, and perhaps the price of the software product.

  • Attempt to engineer a single executable file that contains, at one or multiple points, the necessary internal branching to use or emulate the new instructions, thereby increasing the memory requirement and perhaps degrading performance on every customer's system because of the added branching.

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.



ItaniumR Architecture for Programmers. Understanding 64-Bit Processors and EPIC Principles
ItaniumR Architecture for Programmers. Understanding 64-Bit Processors and EPIC Principles
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 223

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net