Browse files

JIT documentation!

1 parent ef93161 commit f530ef749adb15f53d85b7ddd0e3b4d40c60a196 @DrChat DrChat committed Nov 23, 2016
Showing with 64 additions and 9 deletions.
  1. +64 −9 docs/
  2. BIN docs/images/CPU-JIT.png
@@ -1,15 +1,70 @@
# CPU Documentation
-## Code
+## The JIT
-Xenia uses a dynamic recompiler to recompile PPC instructions to host
-architecture instructions at runtime. Functions are converted as they
-are called by the guest/host and stored in a code cache. Currently, the
-only backend that exists is the x64 backend.
+![JIT Diagram](images/CPU-JIT.png?raw=true)
-Unfortunately, one problem with this approach is that code usually never
-ends up in the same spot across reruns due to multithreading. Host code
-may also morph depending on which spots of a function are called first.
+The JIT is the core of Xenia. It translates Xenon PowerPC code into native
+code runnable on the host computer.
+There are 3 phases to translation:
+1. Translation to IR (intermediate representation)
+2. IR compilation/optimization
+3. Backend emission
+PowerPC instructions are translated to Xenia's intermediate representation
+format in src/xenia/cpu/ppc/ppc_emit_*.cc (e.g. processor control is done in
+[](../src/xenia/cpu/ppc/ HIR opcodes
+are relatively simple opcodes such that any host can define an implementation.
+After the HIR is generated, it is ran through a compiler to prep it for generation.
+The compiler is ran in a series of passes, the order of which is defined in
+[](../src/xenia/cpu/ppc/ Some passes are
+essential to the successful generation, while others are merely for optimization
+purposes. Compiler passes are defined in src/xenia/cpu/compiler/passes with
+descriptive class names.
+Finally, the backend consumes the HIR and emits code that runs natively on the
+host. Currently, the only backend that exists is the x64 backend, with all the
+emission done in
+## ABI
+Xenia guest functions are not directly callable, but rather must be called
+through APIs provided by Xenia. Xenia will first execute a thunk to transition
+the host context to a state dependent on the JIT backend, and that will call the
+guest code.
+### x64
+Transition thunks defined in [](../src/xenia/cpu/backend/x64/
+Registers are stored on the stack as defined by [StackLayout::Thunk](../src/xenia/cpu/backend/x64/x64_stack_layout.h#L96)
+for later transitioning back to the host.
+Some registers are reserved for usage by the JIT to store temporary variables.
+See: [X64Emitter::gpr_reg_map_ and X64Emitter::xmm_reg_map_](../src/xenia/cpu/backend/x64/
+#### Integer Registers
+Register | Usage
+--- | ---
+RAX | Scratch
+RBX | JIT temp
+RCX | Scratch
+RDX | Scratch
+RSP | Stack Pointer
+RBP | Unused
+RSI | PowerPC Context
+RDI | Virtual Memory Base
+R8-R11 | Unused (parameters)
+R12-R15 | JIT temp
+#### Floating Point Registers
+Register | Usage
+--- | ---
+XMM0-XMM5 | Scratch
+XMM6-XMM15 | JIT temp
## Memory
@@ -55,7 +110,7 @@ Programs are still allowed to use 64-bit PowerPC instructions, and registers
are 64-bit as well, but 32-bit instructions will run in 32-bit mode.
The CPU is largely similar to the PPC part in the PS3, so Cell documents
often line up for the core instructions. The 360 adds some additional AltiVec
-instructions, though,which are only documented in a few places (like the gcc source code, etc).
+instructions, though, which are only documented in a few places (like the gcc source code, etc).
* [Free60 Info](\(CPU\))
* [Power ISA docs]( (aka 'PowerISA')
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit f530ef7

Please sign in to comment.