Re: Stack based-Register Based

Vinoth Kumar <vinoth@india.ti.com> schreibt:


> What is the motivation behind designing Java as a stack based,
> when lots of processors around us are register based.


A stack is virtually unlimited, while you always have too few
registers, on any machine.


For Java, the virtual machine will always run on a physical
machine. The virtual machine then can optimize the use of the existing
registers, without any modifications to the Java byte
code. Performance would be bad, if the VM assumed more registers, than
are available on a specific physical CPU.


What is, in your opinion, the difference between values in registers
and values in a stack?




[The following is my opinion, but it may be outdated a bit ;-]


IMO there exists no big difference, only that that the field, for the
register number in a machine instruction, is smaller than the field
for an stack offset.


Operations with values in registers may execute faster, than with
values in a stack, but the ratio cannot be predicted easily. The
values in registers must be loaded and saved, at least whenever a
subroutine or other scope is entered or left.


There exist(ed) processors, which implement their registers in a
stack, and moved the base pointer with every scope change. Many
registers, but all in memory! On some newer machines IMO a data cache
in the CPU can make operations with memory operands nearly as fast as
with register operands. Then the number of "registers in use" can vary
between several versions of the same CPU, whereas the number of
"directly addressable registers" is hard wired in the (machine
architecture? and) instruction set.


On other (RISC) architectures the best usage of the registers IMO can
become very complicated, so that a compiler can optimize the usage of
the registers better than an application programmer. So why bother
with a limited number of registers in a high level language, when
their usage then typically only will /disallow/ the compiler, to
produce the fastest possible code?


DoDi

Return to the comp.compilers page.
Search the comp.compilers archives again.