|Stack based-Register Based email@example.com (Vinoth Kumar) (2001-01-19)|
|Re: Stack based-Register Based firstname.lastname@example.org (2001-01-20)|
|Re: Stack based-Register Based email@example.com (2001-01-20)|
|Re: Stack based-Register Based firstname.lastname@example.org (Roedy Green) (2001-01-26)|
|Re: Stack based-Register Based email@example.com (2001-01-26)|
|identifying symbols firstname.lastname@example.org (Gokul B Kandiraju) (2001-01-26)|
|Re: Stack based-Register Based email@example.com (Andrew Berg) (2001-01-28)|
|Re: Stack based-Register Based firstname.lastname@example.org (2001-02-01)|
|Re: Stack based-Register Based email@example.com (Jonathan Barker) (2001-02-01)|
|[9 later articles]|
|Date:||20 Jan 2001 16:14:06 -0500|
|Organization:||AOL Bertelsmann Online GmbH & Co. KG http://www.germany.aol.com|
|Posted-Date:||20 Jan 2001 16:14:06 EST|
Vinoth Kumar <firstname.lastname@example.org> 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?
Return to the
Search the comp.compilers archives again.