The case against stack-oriented instruction sets

Abstract

Stack-oriented (reverse-Polish-oriented) instruction sets have been claimed to be superior to register-oriented instruction sets.This paper refutes this claim and also shows that a third form is more desirable.Claims have been madeo often emotional in nature [ I], that stack-oriented instructio-s sets (i.e., machines where the majority of instructions implicitly refer to operands on the top of a pushdown stack) are superior to the more-common register-oriented instruction sets.The usual arguments are:I."The code representation roll stack machines] requires much less space than alternative instruction forms with equal range of reference."[ I] "The stack machine, with its zero addresses per instruction, thus appears to be the ultimate step in this trend toward code compaction." [ 2 ] 2. The number of instruction elements (e.g., operation codes, addresses) which must be decoded by the processor is fewer in a stack-oriented machine[ 3 ]. 3.The code-generation process of a compiler is simpler for a stack-oriented machine.The first argument will be shown to be false, the second argument will be shown to be insignificant, and the third argument will be discounted by illustrating a third instruction-set form for which code generation is easier. It should be noted that this discussion only applies to the use of stacks for expression evaluation. It does not refute the claim that stacks are waluable for subroutine management; one should realize that subroutine-managemeIlt stacks can De used with any instruction-set form.The first argument is most important, because the conciseness of an object program not only reduces storage requirements, but it increases performance by optimizing use of the processor/memory bandwidth.It can be shown, for program statements containing long arithmetic or logical expressions, that the instructions generated for a

Virtual machine showdown

“…However, stack machines require more VM instructions for a given computation, each of which requires an expensive (usually unpredictable) indirect branch per VM instruction dispatch. Several authors have discussed the issue [Myers 1977;Schulthess and Mumprecht 1977;McGlashan and Bower 1999;Winterbottom and Pike 1997] and presented small examples where each architecture performs better, but no general conclusions can be drawn without a larger study.…”

“…Interpreting the large amount of rarely executed code in many Java programs avoids the time and memory overhead of compilation and can be faster than JIT compilation. Myers [1977] attempts to refute the idea that stack machines will necessarily result in smaller code, with lower cost to access operands. The argument is based on measurements of real programs which show that the expression in most assignment statements is extremely simple.…”

A stack addressing scheme based on windowing

“…Discussions m [10]- [11], [5]- [7] has demonstrated that zero-operand stack instructions are, in general, inferior to one and two-operands' ones. Keedy [8] further proposed a stack-based instruction set which includes zero, one and two-operands.…”

Instruction Sets for Evaluating Arithmetic Expressions

“…An article in the August 1977 issue of Computer Architecture News [14] set off a debate on the choice of instruction sets for the evaluation of arithmetic expressions [9][10][11]15]. The choices centered around three forms of instructions: (1) memory-memory operations that take both operands from memory and assign the result to one of the operands; (2) register-oriented operations that take one or more operands from registers and assign the result to one of the named registers; and (3) stack-oriented operations that take operands off a hardware stack of registers and leave the result on top of the stack.…”