X64: Call runtime function from JS stack frame.

src/x64/codegen-x64.cc

Index: src/x64/codegen-x64.cc
diff --git a/src/x64/codegen-x64.cc b/src/x64/codegen-x64.cc
index 0fe3e11927526f0e2bb42d704f4777e2f1fa9253..75ba13dcf1b93edd6e732594099c403bfa21e5e2 100644
--- a/src/x64/codegen-x64.cc
+++ b/src/x64/codegen-x64.cc
@@ -429,12 +429,12 @@ void CEntryStub::GenerateCore(MacroAssembler* masm,
                               StackFrame::Type frame_type,
                               bool do_gc,
                               bool always_allocate_scope) {
-  // rax: result parameter for PerformGC, if any
-  // rbx: pointer to C function  (C callee-saved)
-  // rbp: frame pointer  (restored after C call)
-  // rsp: stack pointer  (restored after C call)
-  // rdi: number of arguments including receiver  (C callee-saved)
-  // rsi: pointer to the first argument (C callee-saved)
+  // rax: result parameter for PerformGC, if any.

[William Hesse, 2009/06/12 12:45:04]

What does "result parameter" mean?  This is really just the first (only)
parameter that PerformGC takes?  But why is it on the stack?  Or is it the
return address that a GC call should return to?

[Lasse Reichstein, 2009/06/12 13:09:13]

After the code of GenerateCore, the following code is run only if a failure
happened. In that case, rax holds the resulting failure value. If GenerateCore
is given a true value as do_gc argument, it is used as the parameter to
Runtime::PerformGC.
It is unset until after the first GenerateCore (unless GLAG_gc_greedy is set).
So it's both a result of the C-call and parameter to PerformGC.

[William Hesse, 2009/06/12 14:56:51]

I would comment it as:
// rax: result of the previous call to the function.  Pass it to PerformGC if a
GC is needed.

+  // rbx: pointer to C function  (C callee-saved).
+  // rbp: frame pointer  (restored after C call).
+  // rsp: stack pointer  (restored after C call).
+  // rdi: number of arguments including receiver.

[William Hesse, 2009/06/12 12:45:04]

rdi is also callee-saved.  Maybe specify the Unix/Windows X64 ABI in a comment
above // rax.

[Lasse Reichstein, 2009/06/12 13:09:13]

The rdi register is only callee-save in the Windows X64 ABI, not the Unix X64
ABI (it's a parameter register). We should treat it as volatile except in
MSVC-specific code.
Added comment to that point.

+  // r15: pointer to the first argument (C callee-saved)
 
   if (do_gc) {
     __ movq(Operand(rsp, 0), rax);  // Result.
@@ -455,10 +455,11 @@ void CEntryStub::GenerateCore(MacroAssembler* masm,
 #ifdef __MSVC__
   // MSVC passes arguments in rcx, rdx, r8, r9
   __ movq(rcx, rdi);  // argc.
-  __ movq(rdx, rsi);  // argv.
+  __ movq(rdx, r15);  // argv.
 #else  // ! defined(__MSVC__)
+  __ movq(rsi, r15);  // argv.
   // GCC passes arguments in rdi, rsi, rdx, rcx, r8, r9.
-  // First two arguments are already in rdi, rsi.
+  // First arguments is already in rdi.

[William Hesse, 2009/06/12 12:45:04]

argument

[Lasse Reichstein, 2009/06/12 13:09:13]

fixed.

 #endif
   __ call(rbx);
   // Result is in rax - do not destroy this register!
@@ -588,12 +589,12 @@ void CEntryStub::GenerateBody(MacroAssembler* masm, bool is_debug_break) {
   // Enter the exit frame that transitions from JavaScript to C++.
   __ EnterExitFrame(frame_type);
 
-  // rax: result parameter for PerformGC, if any (setup below)
-  // rbx: pointer to builtin function  (C callee-saved)
-  // rbp: frame pointer  (restored after C call)
-  // rsp: stack pointer  (restored after C call)
-  // rdi: number of arguments including receiver (C callee-saved)
-  // rsi: argv pointer (C callee-saved)
+  // rax: result parameter for PerformGC, if any (setup below).
+  // rbx: pointer to builtin function  (C callee-saved).
+  // rbp: frame pointer  (restored after C call).
+  // rsp: stack pointer  (restored after C call).
+  // rdi: number of arguments including receiver.

[William Hesse, 2009/06/12 12:45:04]

Why isn't this marked as C callee-saved?  Or if it isn't anymore (because it is
now an argument register), then shouldn't it be put in a callee-saved one?

[Lasse Reichstein, 2009/06/12 13:09:13]

It's not callee-saved in the Unix 64-bit ABI, but the values doesn't need to be
saved across the C call anyway, so I kept the value in the parameter register
and removed the "callee-saved" comment.

+  // r15: argv pointer (C callee-saved).
 
   Label throw_out_of_memory_exception;
   Label throw_normal_exception;