ShuriZma
/
xenia-canary
mirror of https://github.com/xenia-canary/xenia-canary.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Add some documentation about the guest memory

This commit is contained in:
DrChat 2016-10-21 13:04:10 -05:00
parent 880835d9b5
commit c8b6dbddbb
1 changed files with 48 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
docs/cpu.md
View File

@ -1,5 +1,47 @@
# CPU Documentation
## Code
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.
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.
## Memory
Xenia defines virtual memory as a mapped range beginning at Memory::virtual_membase(),
and physical memory as another mapped range from Memory::physical_membase()
(usually 0x100000000 and 0x200000000, respectively). If the default bases are
not available, they are shifted left 1 bit until an available range is found.
The guest only has access to these ranges, nothing else.
### Map
```
0x00000000 - 0x3FFFFFFF (1024mb) - virtual 4k pages
0x40000000 - 0x7FFFFFFF (1024mb) - virtual 64k pages
0x80000000 - 0x8BFFFFFF ( 192mb) - xex 64k pages
0x8C000000 - 0x8FFFFFFF ( 64mb) - xex 64k pages (encrypted)
0x90000000 - 0x9FFFFFFF ( 256mb) - xex 4k pages
0xA0000000 - 0xBFFFFFFF ( 512mb) - physical 64k pages (overlapped)
0xC0000000 - 0xDFFFFFFF - physical 16mb pages (overlapped)
0xE0000000 - 0xFFFFFFFF - physical 4k pages (overlapped)
```
Virtual pages are usually allocated by NtAllocateVirtualMemory, and
physical pages are usually allocated by MmAllocatePhysicalMemoryEx.
Virtual pages mapped to physical memory are also mapped to the physical membase,
i.e. virtual 0xA0000000 == physical 0x00000000
Unfortunately, the 0xE0000000-0xFFFFFFFF range is unused in Xenia because
it maps to physical memory with a single page offset, which is impossible
to do under the Win32 API.
## Memory Management
TODO
@ -8,12 +50,12 @@ TODO
### PowerPC
The processor in the 360 is a 64-bit PowerPC chip running with 32-bit memory
addresses. This can make some of the documentation a little confusing as most
of the PowerPC docs only have a 'you're in 32 or 64' style. 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).
The processor in the 360 is a 64-bit PowerPC chip running in 32-bit mode.
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).
* [Free60 Info](http://www.free60.org/Xenon_\(CPU\))
* [Power ISA docs](https://www.power.org/wp-content/uploads/2012/07/PowerISA_V2.06B_V2_PUBLIC.pdf) (aka 'PowerISA')