On Oct 22, 2004, at 3:57 AM, Leopold Toetsch wrote:
Jeff Clites wrote:On Oct 22, 2004, at 1:01 AM, Leopold Toetsch wrote:[JIT changes]I just finished tracking down the source of a couple of JIT test failures on PPC--due to recent changes but only indirectly related, and pointing out things which needed fixing anyway (float register preservation issues). I'll send it in tomorrow after I've had a chance to clean it up and add some comments.
Please make sure to get a recent CVS copy and try to prepare the patch during my night ;)
Of course!
I've changed the PPC float register allocation yesterday, because it did look bogus - i.e. the non-volatile FPRs were allocated but not saved. That should be fixed.
Yep, that was the core of the issue. There's no free lunch--if we use the nonvolatile registers, we need to preserve/restore them in begin/end, but if we use the volatile registers, we need to preserve them across function calls (incl. normal op calls). So I added code to do the appropriate save/restore, and use the non-volatile registers for mapping--that should be less asm than what we'd have to do to use the volatile registers. (The surprising thing was that we only got 2 failures when using the volatile registers--I'll look into creating some tests that would detect problems with register preservation.)
The other tricky part was that saving/restoring the FP registers is one instruction per saved register, so saving all 18 was exceeding the asm size we allocate in src/jit.c (in some cases), since we emit Parrot_end for all restart ops. The fix for this was to pull this asm out into a utility routine, and just call that from the asm. (This is only done for restoring the registers so far--I should do it for the preservation step too, but right now that's just inline.)
The attached patch also contains some other small improvements I'd been working on, and a few more jitted ops to demonstrate calling a C function from a jitted op.
While you're investigating PPC JIT: JIT debugging via stabs doesn't work at all here. I get around the gdb message (missing data segment) by inserting ".data\n.text\n" in the stabs file, but that's all. After this change and regenerating "file.o" I can load it with "add-symbol-file file.o" without any complaint, but the access to the memory region the jitted code occupies is not allowed, disassemble doesn't work ...
I'll take a look and see if I can figure it out. I remember gdb being uncooperative about disassembling, frustratingly, and I've moved to the habit of using something like "x/300i jit_code" as a workaround. Clearly it can access the memory region, so it seems like a gdb bug.
See attached the patch, plus the new asm.s file.
JEff
config/gen/platform/darwin/asm.s:
asm.s
Description: application/applefile
Description: application/text
Description: application/text
