Java instead of freedom - the best option?

Tom Thornhill
Tue, 06 May 1997 16:03:01 +0200

Jeremy Fitzhardinge wrote:
> In article <01bc5949$fabf0a80$725e9082@mniw1001>,
> Actually, the stack nature of the JVM makes very little difference to a
> JIT.  Unlike Forth or PostScript, you can always tell how deep the
> stack is at any point with a static analysis, and you can therefore map
> stack slots onto registers pretty easily.  If you're willing to spend a
> little time on register allocation, the stack architecture has no impact
> on generated code at all (ignoring the complexities of exceptions and
> jsr/ret).
>         J

But if your going to use register allocation why not let the compiler do
it -
surely there are things that you know at compile time but not in a JIT.
the original Risc studies show that memory access falls off with more
as follows

 memory accesses  = Peak ( 1 -exp ( K*number of registers ) )

Peak is for a accumulator machine, and the function levels off for
number of registers >= 30

So if we know that performance increase above 32 regs is negligable, why
not hardcode
this into the VM. On machines with fewer regs we'd have to use the regs
we have as
a cache for off chip memory ( which would be in the on chip data cache
), and there
are unlikely to be mainstream processors with more ( why do I suddenly
see an 
incoming contradiction ;-).


Talkto:Tom Thornhill, Philips Medical Systems Nederland BV
Tel +31 4027 64080 ( Work ), +31 499 371230 ( Hotel - ask for room 19 )
************************ +44 3709 46045 GSM ****************************
**** IMPORTANT: please use the above numbers rather than the GSM *******
****  one if possible as I pay for incoming  calls from outside the **** 
****  Netherlands. *****************************************************