The reason why stack hardware went into a deep slumber is more because of the
advent of caching.
Register-based computations are space wasters because of the number of concepts
that need to be implemented as separate instructions. If you can make
fast-enough cache so that you still have locality, you have a winner: Few cache
faults where the processor sits idle, fast instruction-level execution because
the opcode tell the CPU all it needs to know.
On a stack machine, one can have tiny (byte-size, hence "bytecode")
instructions, because the stack - which contains the operands - knows things
like size, type, in addition to location. So "add" is enough, no need
to have separate codes for "add-long", "add-float",
"add-float-to-double" etc.
With current technologies, and current types of problems to solve,
register-based keeps its momentum. Android was intended to run on off-the-shelf
hardware. Sun was thinking (dreaming?) of a Java physical CPU when this all
started...
Nothing is ever completely obsolete in cyberspace.[ Reply to This | Parent | # ]
|
But actually implementing something as a stack-based instruction set
is an unwise decision. Some of the earliest computers did it because every logic
gate
was expensive. But as soon as the focus changed from "can it be done at
all" to "how to do it well", register based execution models
prevailed.
I call your attention to Sevaried's Law (Google it, if
you wish): "The chief cause of problems is solutions."
The set of
solution-caused problems of any solution in engineering is like a cake, you can
have it or eat it. You can't do both.
Stack architecture is a solution.
Register architecture is a solution. If you are faced with a choice, you must
decide which problems you want to solve, and which ones you want to have. The
register solution causes one set of solution-caused problems. The stack
solution generates another. The choice is between the two sets of resulting
problems. Burroughs and Sun chose one set; other folks choose the
other.
Mostly, though, the choice is a hybrid — some aspects are
register-oriented, some are stack-oriented. Hardly anybody, any more, tries to
implement procedure/function calling without some sort of stack — even for
C. But token-oriented architectures, like Java and the Burroughs Large Systems,
present interesting issues when addressing is mixed in with operations, as in
opcode+register or opcode+two-registers instruction format. RPN (implying a
stack) separates addressing from operation, making token-fondling less of an
issue.
What problems do you want to have to solve, based on your
solution? ---
--Bill. NAL: question the answers, especially mine. [ Reply to This | Parent | # ]
|
