On Mon, Aug 05, 2002 at 12:41:45AM -0300, Daniel Grunblatt wrote:I'm not quite sure I follow you here.
> On Sun, 4 Aug 2002, Nicholas Clark wrote:
> > Plus I was using r4 as my interpreter pointer, and I suspect you don't want
> > to map that out.
> True, I won't use r0 either as it's the register we need to use in the
I've looked a bit at the code, and I think what it's doing is looking for
sections between ops that branch to C functions.
Ops that branch are either ops that aren't JITted (so they call the regular
C implementation), or ops that don't happen to inline a C function call.
[er, I've not worked out what the code is doing about ops that branch
If you're in a section between branches, then on ARM all the registers are
I'm not sure if your map code allows a JIT op to say "I need a temporary
Also, across the section with branches, the ARM ABI says that r4-r10 are
This would suggest to me that the map code should be able to treat each op
Maybe this is too complex to do right now, but the short version is that I
> > The other thing I was thinking about, but hadn't yet needed toI wasn't directly meaning those two functions. I was thinking about the
> > consider was that my entry code was only saving r4 (from that list)
> > and restoring it on exit. I was envisaging making a new fixup type
> > (probably only one needed both for the stm and the ldm) that is pushed
> > onto the fixup chain to mark the stm on entry, and the ldm in each end
> > op (where the subroutine can return). There would be an entry in some
> > part of the jit info structure, and
> > as the mapper found it needed each extra register from r4-r10 it would record
> > this in the jit info structure, and then when the fixups run, they'd adjust
> > all the ldm and stm instructions to preserve exactly the minimum set of
> > registers needed.
> > Of course the simpler approach right now is to save all of r4-r10 and not be
> The idea of Parrot_jit_(load|save)_registers is to load/save only the
function entry code, and the code generated by the end op, which returns from
the function generated by the JIT.
On ARM, you need to preserve r4-r10, which is normally done by pushing them
I was thinking that they way the parrot works at the moment it writes out the
a: mark the entry point and each exit point with a fixup
> > It might be easier if I let you get on with integrating the mapper intoWell, with all this JIT stuff I did find nicer arm optimisation for !a than
> > the arm jit, and work on some perl5 stuff for a few evenings, rather than
> > fiddle with arm stuff that has merge conflicts with what you're doing.
> I will, no promises on when, I want to get some things done for the
> > [I could even do something non perl! :-)]
> But it won't be *THAT* fun, will it? ;)
gcc currently knows, and someone's told me exactly which bit of which file in
gcc is the relevant bit of the arm peephole optimiser, so all I have to do is
free up enough disk space to build gcc...
[no, freeing up disk space isn't fun, so you're correct there :-(]
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.