I'm not quite sure I follow you here.
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
elsewhere in the subroutine the JIT is working on, or the targets of those
branches.]

If you're in a section between branches, then on ARM all the registers are
free for you to use. I suspect that other CPUs are similar - within your code
you can use most or all registers, but when you call or return registers must
be in a controlled state. On ARM, the non-JIT op before won't have anything
useful in r0, while the JIT op that did a branch may well do (as its output).
But inside the block of code being built up by the JIT, where the JIT knows
there are no branches in or out, then all the registers are its to use as it
sees fit. So r0 is no different from r1 or r2.

I'm not sure if your map code allows a JIT op to say "I need a temporary
register" (or more generally "I need n temporary registers", where n will
often be zero) I don't yet think I've needed to use more registers than were
being used for IN and OUT, but given more complex ops it will be necessary.
For example, set NUM, NUM would best be done by copying via the hardware
(integer) registers, ie avoid using floating point registers. I suspect other
CPUs will be similar, in that some ops will want to use one or more scratch
registers that would normally be available to the map code.

Also, across the section with branches, the ARM ABI says that r4-r10 are
preserved. So the map code could quite happily map intermediate values into
any of them (or at least r5-r9) and know that they will be preserved after
a non-JIT op, or (if it is written to conform with this) any JIT op that makes
an external branch. I presume that other CPUs will also have some sort of
split - some registers are preserved across a function call, others are not.
While inside a function you can use the preserved registers as you see fit
(providing you save and restore them at entry and exit)

This would suggest to me that the map code should be able to treat each op
as preserving a set of registers, and potentially corrupting all others.
The default for regular JIT ops would be that they preserve all registers
apart from those that are explicitly mapped as output; the default for ops
that call out to C functions would be that they preserve and corrupt as for
that platform's ABI.

Maybe this is too complex to do right now, but the short version is that I
don't see why r0 needs to be special in the map code for ARM.

I wasn't directly meaning those two functions. I was thinking about 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
onto the stack at entry, and popping them at exit. However, the C compiler
knows which of r4-r10 it used, and generates the minimal code needed to only
store the ones it used. (as the save and restore of a register that is never
actually changed wastes time)

I was thinking that they way the parrot works at the moment it writes out the
function entry code before it starts processing parrot ops, so at that time it
has no idea how many registers it's going to use. Also, if a function has
several return points, it will write end op before it reaches the end of the
function. And it may find that near the end of the function it encounters
code that requires it to start fusing lots of CPU registers. So the JIT won't
actually know which CPU registers it needs to save/restore until it finishes
the last parrot op of the function. Hence the JIT would need to

a: mark the entry point and each exit point with a fixup
b: track how many registers it used in the map code
c: fixup the entry and exit points to preserve the registers it did use.

Well, with all this JIT stuff I did find nicer arm optimisation for !a than
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 :-(]

Nicholas Clark
--
Even better than the real thing:        http://nms-cgi.sourceforge.net/