search for: areg0

...explicitly specifying a calling convention for the functions, but LLVM seems to consistently put the ARM CPU state struct pointer (parameter) into %rdi. As a hack-around (since posting the original message to the list) I'm injecting a couple of MOV instructions to move the pointer from %r14 (AREG0 - TCG's pointer to the CPU state struct on x86_64) to %rdi before and back (from %rdi) to %r14 after the copied function block. Implementing a custom calling convention would avoid the injected MOVs, saving two instructions per block I guess. This isn't a huge win, and as such isn't...

...istently put the ARM CPU state struct > pointer (parameter) into %rdi. That's correct - please consider reading x86-64 ABI document. > As a hack-around (since posting the original > message to the list) I'm injecting a couple of MOV instructions to move the > pointer from %r14 (AREG0 - TCG's pointer to the CPU state struct on x86_64) Use inline assembler to load the address of this struct, this is much better than implementing a new calling convention. > to %rdi before and back (from %rdi) to %r14 after the copied function block. You don't need this - I doubt you...

Hi Andrew, On Wed, Sep 23, 2009 at 7:26 AM, Andrew Jeffery <andrew at aj.id.au> wrote: > TCG seperates the guest (ARM) code into blocks - my front end translates > these to LLVM IR for LLVM to translate to x86.  The assumption is that LLVM > will produce a better translation than TCG*. At some future point the > TCG-generated native block is replaced by the LLVM's, and as

Anton Korobeynikov wrote: > Ok, what's left from QEMU then? :) The hardware emulation (interrupts, condition flags, register file etc) and execution framework (block selection and execution) from qemu are still used - translating the ARM to the native architecture is only part of the story :) > >> generating reasonable code - this approach keeps it in place while we do