Re: Stack based-Register Based (VBDis)
20 Jan 2001 16:14:06 -0500

          From comp.compilers

Related articles
Stack based-Register Based (Vinoth Kumar) (2001-01-19)
Re: Stack based-Register Based (2001-01-20)
Re: Stack based-Register Based (2001-01-20)
Re: Stack based-Register Based (Roedy Green) (2001-01-26)
Re: Stack based-Register Based (2001-01-26)
identifying symbols (Gokul B Kandiraju) (2001-01-26)
Re: Stack based-Register Based (Andrew Berg) (2001-01-28)
Re: Stack based-Register Based (2001-02-01)
Re: Stack based-Register Based (Jonathan Barker) (2001-02-01)
[9 later articles]
| List of all articles for this month |

From: (VBDis)
Newsgroups: comp.compilers
Date: 20 Jan 2001 16:14:06 -0500
Organization: AOL Bertelsmann Online GmbH & Co. KG
References: 01-01-124
Keywords: interpreter, design
Posted-Date: 20 Jan 2001 16:14:06 EST

Vinoth Kumar <> 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?


Post a followup to this message

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