Nicholas Clark wrote:
On Tue, Oct 29, 2002 at 08:26:00AM +0100, Leopold Toetsch wrote:
But then you end up with a messier two level register spillage problem at
compile time, don't you?
Yes.
...Which values to spill from fast to slow registers,
and which values to spill further from slow
On Tue, Oct 29, 2002 at 08:26:00AM +0100, Leopold Toetsch wrote:
> Dan Sugalski wrote:
> > I'm currently leaning against it only because it doesn't ultimately help
> > the JIT. What we have now is wildly cool and damn useful (and has anyone
> > heard from Daniel lately, BTW?) but there's room fo
Dan Sugalski wrote:
At 7:09 PM +0100 10/27/02, Leopold Toetsch wrote:
So the I-register access is substituted by access to 3 global integers.
Now, how would these globals be loaded? When are these »arg« OPs
inserted?
Currently the register optimizer in jit.c does something very similar:
Set
At 7:09 PM +0100 10/27/02, Leopold Toetsch wrote:
So the I-register access is substituted by access to 3 global integers.
Now, how would these globals be loaded? When are these »arg« OPs inserted?
Currently the register optimizer in jit.c does something very
similar: Setting up register access f
When looking at the inner loop of mops.pasm by far the most time is used
for accessing the parrot registers.
Some results (-O3 compiled except run_ops_cg.c, Athlon 800, i386/linux):
CVS »micro_ops«
-g (fast_core) 24 117
cgoto_core:
19
205
-j (JIT) 782
So I hacked together a modified core.op
