Add some documentation about the guest memory
This commit is contained in:
parent
880835d9b5
commit
c8b6dbddbb
54
docs/cpu.md
54
docs/cpu.md
|
@ -1,5 +1,47 @@
|
||||||
# CPU Documentation
|
# 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
|
## Memory Management
|
||||||
|
|
||||||
TODO
|
TODO
|
||||||
|
@ -8,12 +50,12 @@ TODO
|
||||||
|
|
||||||
### PowerPC
|
### PowerPC
|
||||||
|
|
||||||
The processor in the 360 is a 64-bit PowerPC chip running with 32-bit memory
|
The processor in the 360 is a 64-bit PowerPC chip running in 32-bit mode.
|
||||||
addresses. This can make some of the documentation a little confusing as most
|
Programs are still allowed to use 64-bit PowerPC instructions, and registers
|
||||||
of the PowerPC docs only have a 'you're in 32 or 64' style. The CPU is largely
|
are 64-bit as well, but 32-bit instructions will run in 32-bit mode.
|
||||||
similar to the PPC part in the PS3, so Cell documents often line up for the
|
The CPU is largely similar to the PPC part in the PS3, so Cell documents
|
||||||
core instructions. The 360 adds some additional AltiVec instructions, though,
|
often line up for the core instructions. The 360 adds some additional AltiVec
|
||||||
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](http://www.free60.org/Xenon_\(CPU\))
|
* [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')
|
* [Power ISA docs](https://www.power.org/wp-content/uploads/2012/07/PowerISA_V2.06B_V2_PUBLIC.pdf) (aka 'PowerISA')
|
||||||
|
|
Loading…
Reference in New Issue