1. 02 Dec, 2010 1 commit
  2. 20 Oct, 2010 1 commit
  3. 10 Aug, 2010 1 commit
  4. 06 Jul, 2010 1 commit
  5. 25 Apr, 2010 1 commit
  6. 09 Apr, 2010 1 commit
  7. 01 Apr, 2010 1 commit
    • Aurelien Jarno's avatar
      tcg: initial ia64 support · 477ba620
      Aurelien Jarno authored
      A few words about design choices:
      * On IA64, instructions should be grouped by bundle, and dependencies
        between instructions declared. A first version of this code tried to
        schedule instructions automatically, but was very complex and too
        invasive for the current common TCG code (ops not ending at
        instruction boundaries, code retranslation breaking already generated
        code, etc.)  It was also not very efficient, as dependencies between
        TCG ops is not available.
        Instead the option taken by the current implementation does not try
        to fill the bundle by scheduling instructions, but by providing ops
        not available as an ia64 instruction, and by offering 22-bit constant
        loading for most of the instructions. With both options the bundle are
        filled at approximately the same level.
      
      * Up to 128 registers can be affected to a function on IA64, but TCG
        limits this number to 64, which is actually more than enough. The
        register affectation is the following:
        - r0: used to map a constant argument with value 0
        - r1: global pointer
        - r2, r3: internal use
        - r4 to r6: not used to avoid saving them
        - r7: env structure
        - r8 to r11: free for TCG (call clobbered)
        - r12: stack pointer
        - r13: thread pointer
        - r14 to r31: free for TCG (call clobbered)
        - r32: reserved (return address)
        - r33: reserved (PFS)
        - r33 to r63: free for TCG
      
      * The IA64 architecture has only 64-bit registers and no 32-bit
        instructions (the only exception being cmp4). Therefore 64-bit
        registers and instructions are used for 32-bit ops. The adopted
        strategy is the same as the ABI, that is the higher 32 bits are
        undefined. Most ops (and, or, add, shl, etc.) can directly use
        the 64-bit registers, while some others have to sign-extend (sar,
        div, etc.) or zero-extend (shr, divu, etc.) the register first.
      Signed-off-by: default avatarAurelien Jarno <aurelien@aurel32.net>
      477ba620
  8. 21 Mar, 2010 1 commit
  9. 12 Mar, 2010 1 commit
  10. 09 Feb, 2010 1 commit
  11. 01 Oct, 2009 2 commits
  12. 25 Aug, 2009 1 commit
  13. 24 Aug, 2009 1 commit
    • Anthony Liguori's avatar
      Unbreak large mem support by removing kqemu · 4a1418e0
      Anthony Liguori authored
      kqemu introduces a number of restrictions on the i386 target.  The worst is that
      it prevents large memory from working in the default build.
      
      Furthermore, kqemu is fundamentally flawed in a number of ways.  It relies on
      the TSC as a time source which will not be reliable on a multiple processor
      system in userspace.  Since most modern processors are multicore, this severely
      limits the utility of kqemu.
      
      kvm is a viable alternative for people looking to accelerate qemu and has the
      benefit of being supported by the upstream Linux kernel.  If someone can
      implement work arounds to remove the restrictions introduced by kqemu, I'm
      happy to avoid and/or revert this patch.
      
      N.B. kqemu will still function in the 0.11 series but this patch removes it from
      the 0.12 series.
      
      Paul, please Ack or Nack this patch.
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      4a1418e0
  14. 16 Jun, 2009 1 commit
  15. 19 May, 2009 1 commit
    • Paul Brook's avatar
      Hardware convenience library · 1ad2134f
      Paul Brook authored
      The only target dependency for most hardware is sizeof(target_phys_addr_t).
      Build these files into a convenience library, and use that instead of
      building for every target.
      
      Remove and poison various target specific macros to avoid bogus target
      dependencies creeping back in.
      
      Big/Little endian is not handled because devices should not know or care
      about this to start with.
      Signed-off-by: default avatarPaul Brook <paul@codesourcery.com>
      1ad2134f