Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Paul Khuong <pkhuong@gm...> - 2008-10-01 13:59:44
On 29-Sep-08, at 8:13 AM, Vitaly Mayatskikh wrote:
> Register RCX was used twice for arguments loading in call_into_c.
> --- sbcl/src/runtime/x86-64-assem.S.orig 2008-07-04
> 17:36:12.000000000 +0200
> +++ sbcl/src/runtime/x86-64-assem.S 2008-09-29 13:56:30.000000000
> @@ -114,9 +114,8 @@ GNAME(call_into_c):
> mov 24(%rbp),%rsi
> mov 32(%rbp),%rdx
> mov 40(%rbp),%rcx
> - mov 48(%rbp),%rcx
> - mov 56(%rbp),%r8
> - mov 64(%rbp),%r9
> + mov 48(%rbp),%r8
> + mov 56(%rbp),%r9
> call *%rax
> mov %rbp,%rsp
> pop %rbp
I don't know how long this has been around, but, AFAICT, call_into_c
is only used in the PRINT (as in cold debug print) VOP, with a single
argument, on x86-64. Would it make sense to call debug_print directly
and lose call_into_c?
On Wed, Oct 1, 2008 at 3:59 PM, Paul Khuong <pkhuong@...> wrote:
> I don't know how long this has been around, but, AFAICT, call_into_c
> is only used in the PRINT (as in cold debug print) VOP, with a single
> argument, on x86-64. Would it make sense to call debug_print directly
> and lose call_into_c?
Probably, possibly. Even though call_into_c can save a bit of space,
maintaining two version of the same code is badness waiting to happen.