lightning
[Top][All Lists]
Advanced

[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'.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]