[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Lightning] release gets closer...
From: |
Ludovic Courtès |
Subject: |
Re: [Lightning] release gets closer... |
Date: |
Wed, 22 Nov 2006 11:41:03 +0100 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) |
Hi Paolo,
Patch-36 in my branch fixes the function epilogue on IA32 and x86-64
wrt. `allocai'. Basically, %esp was not restored to its original value
before %edi et al. were popped. Note that I only tested it on IA32, not
on x86-64. Also, I was unable to tweak `tests/allocai.c' so that it
systematically catches the problem.
Speaking of this, wouldn't a patching approach for `allocai' (as on
SPARC and PPC) be more efficient on Intel, instead of generating a `push
%eax' or similar for each `allocai'? More importantly, not using the
same approach as on SPARC and PPC yields semantic changes. Consider the
following code:
ref = jit_bnei (jit_forward (), ...);
offset = jit_allocai (sizeof (int));
jit_patch (ref);
jit_stxi_p (offset, JIT_FP, JIT_R0);
On i386, the `allocai' is performed at run-time, and it may be skipped
before `stxi' is reached. However, on the other platforms, this would
work well, i.e., the allocated area is always available when `stxi' is
executed.
Regarding `JIT_NEED_PUSH_POP', I think it'd be a good idea to only
define `jit_pushr' and `jit_popr' when it is defined (as is the case
with the SPARC back-end). This would give a strong incentive for people
to switch to `allocai'.
That's it for now.
Thanks,
Ludovic.
PS: BTW, this mailing list is now reachable via Gmane as
`gmane.comp.gnu.lightning.general'.