There are a great many parallels between the introduction of the i860 in 1989 and the planned introduction of the Itanium (Merced) processor later this year. In both cases the powerful Intel marketing engine was put into overdrive and exerted a strong influence over the computer, and electrical engineering trade periodicals. Then, as now, most of the trade press echoed Intel’s assertion that their new super chip was a tremendous new force on the scene that would make life hard for existing RISC vendors for the workstation and server market.
What is striking is that many of the same kind of claims made eleven years ago for the i860 are now being made for IA-64 processors. Even some of the language being used to hype the new processor is nearly identical to that used more than a decade earlier as shown in my introduction. In 1989 it was sufficient for Intel to claim the i860 was RISC-like but better. But in the late 1990’s Intel’s marketing department was faced with managing the introduction of Intel’s own 64-bit RISC-like processor to eventually replace x86 after they spent ten years telling their customers they didn’t need to replace their x86 machines with competing RISC-based computers. To solve this dilemma they came up with the term EPIC or Explicitly Parallel Instruction Computing to explain that not only is the IA-64 architecture not only better than RISC but deserving of an entirely new category.
The most ironic aspect of the parallels between i860 and IA-64 is that many supposedly unique characteristics of IA-64 are merely extensions of the novel features found a decade earlier in the i860 that failed to deliver on their performance promise because compilers of that era found them so difficult to use effectively. One of the most important features of EPIC and IA-64 is explicit parallelism. After all it is the basis of the acronym “EPIC”. In IA-64 explicit parallelism is provided by a five bit wide template field in the 128 bit long bundle that incorporates three instructions. The instructions within a bundle are not necessarily all grouped together. Instruction grouping is indicated by the value in the template (along with the assigned functional unit of each instruction within the bundle). An instruction group is a collection of one or more instructions that collectively fulfill a set of rules against interdependency to ensure that all of the instructions in the group can potentially be executed simultaneously. An IA-64 bundle could include as many as two instruction groups but an instruction group could extend over many bundles. This scheme is illustrated in Figure 3. But this scheme is not conceptually any different from the explicit encoding of entry into, and exit out of, dual instruction mode (DIM) using a dedicated bit in the instruction word used by the Intel i860 RISC microprocessor (and a good argument why IA-64 is undeserving of an entirely new category in computer architecture).
Another feature of IA-64 is the rotating register scheme used to assist software pipelining of program loops. Of the 128 general purpose registers R0 through R127, the upper 96 can be “rotated” by changing the value in the general register rename base (rrb.gr) field in the IA-64 Current Frame Marker register. Similarly, the upper 96 of the 128 floating point register F0 through F127 can be rotated by changing the value in the floating point register rename base (rrb.fr) field in the Current Frame Marker register. The IA-64 includes a number of branch instructions that decrement the values in both register rename base fields as a side effect. This causes it to appear to the software that the value previously in R32 is now in R33, R33’s old value is now in R34 and so on until finally R127’s old value is now in R32. This scheme is shown in Figure 4. It should be noted that segments of IA-64 code employing register rotation are as non-intuitive and convoluted as was i860 code that used pipelined floating point instructions.
Discuss (16 comments)