| Previous | Table of Contents | Next |
This problem is not limited to just the PC industry. Hardware technology has advanced to the point that all new processors will be 64 bits wide. To take advantage of the larger hardware, much of today’s 32-bit operating system and 32-bit application software will have to be rewritten; and this, too, will take many years.
In the examples I have just used, the hardware changes were the number and size of the processor’s registers. Keep in mind that similar impacts on assembler-level software may occur when changes are made to the processor’s addressing structure or to the instruction set itself.
The intention of programming only in an HLL is to minimize the impact on software when the hardware changes described in the preceding paragraphs occur. Unfortunately, the trend for writing system software is to move to a language such as C or C++. Using C helps the portability of the system software because C is available on so many hardware platforms, but it doesn’t eliminate all the difficulties that occur when the hardware changes. Certain hardware characteristics, such as the size of the internal processor, will show through the C language. This capability to see the internals appeals to system programmers and explains the popularity of C. C has been called “today’s assembler.” Moving from a 32-bit processor to a 64-bit processor in a conventional computer system will, for example, still require changes to a C program if it is to take advantage of the larger size. This does take away from C’s portability.
To illustrate the difficulty, consider Digital’s experience. Digital has been shipping systems for several years with its 64-bit Alpha processor. Yet the two major operating systems used in these computers, Digital’s Open VMS and Microsoft’s NT, are both still only 32-bit operating systems, even though they are primarily written in C. Applications running with either of these operating systems are also using only 32 bits. Recompiling doesn’t help. Those operating systems and applications will have to be totally rewritten to use the full resources of the processor and this will take many years.
HP is also pushing its HP 9000 customers into this conversion quagmire. HP is now shipping the 64-bit versions of its PA-RISC processors. HP customers will have to wait for a new 64-bit operating system and then rewrite their applications to take advantage of the new hardware. Again, this will take many years, and there are now indications that HP may abandon the HP 9000 long before the software conversion to 64 bits ever occurs (see Chapter 12).
The secret to the AS/400’s success in completing the transition to 64-bit computing while no other system has done so lies in its architecture.
Many different ways have been devised to classify computer architectures. Probably the oldest is to characterize the formats of the instructions implemented in the processor. Another that we have already seen is to group processors into the CISC or RISC categories. Both approaches focus only on the processor’s hardware interface. From a customer perspective, the applications are far more important than the type of processor in the system. Therefore, it is equally appropriate to classify a computer architecture according to how an application deals with the hardware interface.
The vast majority of computer architectures in use today are based on the traditional approach of exposing the hardware interface to the application programmer. These are called processor-centric architectures because all applications see and directly use the hardware interface. Examples of processor-centric architectures are HP’s PA-RISC and Digital’s Alpha architecture.
Because of the difficulties caused by processor-centric architectures, many ISVs, hardware vendors, and standards organizations have worked together to create architectures based on application programming interfaces (APIs). These API-centric architectures define a communications boundary — an interface — that all applications can use to access the services of the operating system, without getting tied to the specific hardware or software details.
An operating system is a collection of programs that manages the system resources and provides a base for writing application programs. Often, the base for writing the application programs is provided through APIs. An API can take several forms. It might be a call or a command to the operating system to perform some function. A familiar example of an API would be a call by the application program requesting the operating system to perform an I/O operation, such as a disk read. Clearly, the application program does not need to know about the internal workings of the I/O. The operating system programs that perform the I/O functions, often called I/O subsystems, insulate the applications from the hardware and software details. As long as application programs use these APIs to perform their I/O operations, they remain independent of any changes to the underlying I/O structure.
Another benefit occurs if multiple computer vendors implement the same set of APIs. When this happens, an application written only to this set of APIs can easily be moved from one system to another. One of the best known collections of standard APIs is POSIX. POSIX, an acronym loosely defined as “a portable operating system interface based on Unix,” is a collection of international standards for Unix-style operating system interfaces. Vendors of Unix-style operating systems are encouraged by government agencies and businesses alike to implement these standards so that an application can be moved from one system to another.
A problem with a standard such as POSIX is that it is never finished, with the definition phase taking many years to complete. Within this context, application developers often take matters into their own hands. In 1993, a group of Unix application developers and Unix system providers got together to define their own APIs. They couldn’t wait for POSIX to be defined to a point where it would be usable for real-world applications. Besides, at some time in the future when POSIX would be fully defined, all applications would have to be rewritten to meet the new standard.
| Previous | Table of Contents | Next |