cti functions and emit_op_new_array
Hi!! Trying to understand cti functions on the example of emit_op_new_array functions. Here is the code of emit_op_new_array void JIT::emit_op_new_array(Instruction* currentInstruction) { JITStubCall stubCall(this, cti_op_new_array); stubCall.addArgument(Imm32(currentInstruction[2].u.operand)); stubCall.addArgument(Imm32(currentInstruction[3].u.operand)); stubCall.call(currentInstruction[1].u.operand); } As I understand stubCall.call(currentInstruction[1].u.operand) calls function DEFINE_STUB_FUNCTION(JSObject*, op_new_array) from JITStubs.cpp. And at this point execution of our JS programm is "interputing" and here C functions starting to work to "create array". The question is how can I get reference to the craeted array to manipulate it in future? And in general, can anyone please explain in detail how this scheme of cti functions works? Thanks!
On Mar 31, 2012, at 6:13 AM, wingoog moon <wingoog91@gmail.com> wrote:
stubCall.call(currentInstruction[1].u.operand) calls function DEFINE_STUB_FUNCTION(JSObject*, op_new_array) from JITStubs.cpp. And at this point execution of our JS programm is "interputing" and here C functions starting to work to "create array".
Just to be clear, this line of code does not directly call the cti helper stub, this is compiling JIT code, that when run will call the helper stub. Local variables & temporary values between operations are stored in the VM's register file, indexed by virtual register numbers. For the new_array opcode (and most opcodes) the virtual register indicating where to store the result in is stored in the bytecode instruction stream immediately after the opcode - and is being accessed here by the expression "currentInstruction[1].u.operand". The argument to the call method here is the virtual register number to store the result back to. G. Sent from my iPhone
I've tried to debug DEFINE_STUB_FUNCTION(JSObject*, op_new_array) function, and here what my disassemble showed when I tried to go up and see who called this function. Dump of assembler code from 0x7fffb5c98349 to 0x7fffb5c98389: 0x00007fffb5c98349: add %al,(%rax) 0x00007fffb5c9834b: mov %rax,0x0(%r13) 0x00007fffb5c9834f: movl $0x0,0x8(%rsp) 0x00007fffb5c98357: movl $0x1,0x10(%rsp) 0x00007fffb5c9835f: mov %rsp,%rdi 0x00007fffb5c98362: mov %r13,0x58(%rsp) 0x00007fffb5c98367: movl $0x5,-0x2c(%r13) 0x00007fffb5c9836f: movabs $0xc60d60,%r11 0x00007fffb5c98379: mov %r13,(%r11) 0x00007fffb5c9837c: movabs $0x5bfda6,%r11 0x00007fffb5c98386: callq *%r11 This code is generated by emit_op_new_array. Everything is understandable except "movabs $0x5bfda6,%r11". Let's look to the Call function in MacroAssemblerx86_64.h which generates call instruction. Call call() { DataLabelPtr label = moveWithPatch(TrustedImmPtr(0), scratchRegister); Call result = Call(m_assembler.call(scratchRegister), Call::Linkable); ASSERT_UNUSED(label, differenceBetween(label, result) == REPTACH_OFFSET_CALL_R11); return result; } And here we move TrustedImmPtr(0) to scratchRegister(%r11). So the question is how movabs $0x5bfda6,%r11 generated? Is it kind a magic ??)) Thanks! On Sat, Mar 31, 2012 at 8:56 PM, Gavin Barraclough <barraclough@apple.com>wrote:
On Mar 31, 2012, at 6:13 AM, wingoog moon <wingoog91@gmail.com> wrote:
stubCall.call(currentInstruction[1].u.operand) calls function DEFINE_STUB_FUNCTION(JSObject*, op_new_array) from JITStubs.cpp. And at this point execution of our JS programm is "interputing" and here C functions starting to work to "create array".
Just to be clear, this line of code does not directly call the cti helper stub, this is compiling JIT code, that when run will call the helper stub. Local variables & temporary values between operations are stored in the VM's register file, indexed by virtual register numbers. For the new_array opcode (and most opcodes) the virtual register indicating where to store the result in is stored in the bytecode instruction stream immediately after the opcode - and is being accessed here by the expression "currentInstruction[1].u.operand". The argument to the call method here is the virtual register number to store the result back to.
G.
Sent from my iPhone
participants (2)
-
Gavin Barraclough
-
wingoog moon