|
|
|
|
|
|
|
data values for such machines. Still, they represent a baseline for architectural comparison that is not sensitive to register allocation strategy. |
|
|
|
|
|
|
|
|
The register allocator is a special part of the program optimization process, an issue that we discuss later. |
|
|
|
| |
|
|
|
|
VAX implementations have been widely distributed throughout the university and scientific user communities. The VAX instruction set is a product of the late 1970s, when designers gave considerably more thought to code density than to pipelined implementations. In fact, it could be argued that pipelined implementations were the furthest thing from their minds. In a major retrospective study by Bhandarkar and Clark [34], VAX implementations of the late '80s were compared with a contemporary, MIPS R2000. Their study indicated that VAX required between 1.8 and 3.7 times as many cycles to execute a program as the MIPS (L/S) or RISC-type implementation. Their term for this factor was ''the RISC factor." We believe it is better viewed as "the VAX factor." |
|
|
|
|  |
|
|
|
|
Instruction sets are the product of their times, but they often outlive their times and the technology constraints on their times. Another way of looking at the situation is that VAX implementations can match RISC implementations, but to do so requires an extraordinary amount of hardware. Consider the remark by Bhandarkar and Clark:So while VAX may "catch up" to current single-instruction-issue RISC performance, RISC designs will push on with earlier adoption of advanced implementation techniques, achieving still higher performance. The VAX architectural disadvantage might thus be viewed as a time lag of some number of years. |
|
|
|
| |
|
|
|
|
In reacting to VAX instruction set problems, some L/S instruction set designs make the opposite mistake of ignoring code density. Fortunately, this is usually somewhat of an easier problem to fix later (by adding additional complex instructions) than the VAX encoding problem. |
|
|
|
|
|
|
|
|
|
The occurrence (per HLL operation) of certain types of instructions is relatively independent of the architecture used and the degree of compiler optimization employed (excluding only very naive compilers). They are already in 1:1 correspondence with dynamic high-level language actions. These instruction classes generally include: |
|
|
|
|
|
|
|
|
1. Integer multiply and divide. |
|
|
|
|
|
|
|
|
2. Floating-point operations. |
|
|
|
|
|