PPC JIT questions
Peter Montagner
questions:
1) Is the "Red Zone" (the area below the stack) available to JITed ops
or is there stack weirdness going on? Can I do this to temporarily
save a double to memory?
jit_emit_stfd(NATIVECODE, FSR1, -32, r1);
It will be loaded again sometime later in the op. Purely temporary.
This is mainly needed for num to int conversions (set_i_n).
2) What's the procedure for emitting ops that call a C function (like
the string ops)?
I assume that I just do what Parrot_jit_normal_op() does (fixups etc).
normal_op() is entered into the op_jit table with extcall being 1
(presumably because it makes an external call). Do I have to do that
for my ops (can I)? I notice that the i386 ops that call other
functions don't do that. I'm a bit confused.
Thanks,
Peter
Dan Sugalski
>Hi, I'm starting to play with the PPC JIT code and I have a couple
>of questions:
>
>1) Is the "Red Zone" (the area below the stack) available to JITed
>ops or is there stack weirdness going on?
Not a safe one, no. You can extend the stack, of course, but don't
use memory past the stack top, if you do it'll get stomped any time
that an interrupt happens in the middle of the op. It's a very small,
but definitely non-zero chance of error, and those are the absolute
worst to try and track down.
>2) What's the procedure for emitting ops that call a C function
>(like the string ops)?
Just call 'em, unless you think you're in a position to emit
functionally equivalent code that doesn't need the call, which is
definitely possible, though at this stage of things it probably won't
happen. Even if you don't cut out all the overhead, you'll at least
cut out some of it.
We might want to look into compiling the ops files with gcc's "don't
emit header and footer code" option. Might be worth it, might not be
worth it, at least for the JIT.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Peter Montagner
> At 9:42 PM +1000 4/25/03, Peter Montagner wrote:
>> Hi, I'm starting to play with the PPC JIT code and I have a couple of
>> questions:
>>
>> 1) Is the "Red Zone" (the area below the stack) available to JITed
>> ops or is there stack weirdness going on?
>
> Not a safe one, no. You can extend the stack, of course, but don't use
> memory past the stack top, if you do it'll get stomped any time that
> an interrupt happens in the middle of the op. It's a very small, but
> definitely non-zero chance of error, and those are the absolute worst
> to try and track down.
Are you sure? It wasn't an interrupt that I was worrying about, it was
other Parrot stuff. IIRC, the kernel guarantees that it won't touch the
224 bytes below the stack pointer (this is the called the red zone).
GCC uses the red zone for small functions that don't need a stack
frame. In fact, I'm basically just copying what GCC does for the ops I
want.
This is all Mac OS X specific and I don't know if it's correct in the
general PPC sense.
If I can't use the stack, is there a place where I can store a double
temporarily? This double is an intermediate result so I can't use the
address of one of the NUM_REGS.
>> 2) What's the procedure for emitting ops that call a C function (like
>> the string ops)?
>
> Just call 'em, unless you think you're in a position to emit
> functionally equivalent code that doesn't need the call, which is
> definitely possible, though at this stage of things it probably won't
> happen. Even if you don't cut out all the overhead, you'll at least
> cut out some of it.
The problem I see is that the PPC passes arguments to functions in
registers. To call string_copy(), I'd have to set r3 and r4 to the
arguments I'm passing. Doesn't that trash whatever is mapped in r3 and
r4?
Registers r2-r10 are possibly used for mapping and these are *not*
preserved across a function call. They could get trashed. Or am I
missing a save somewhere?
Peter