Modern Core i7's have 4-6 hardware cores with 8-12 hardware threads - enough to pin the threads used on a 360 to their own dedicated hardware threads on the host. Comparing against a desktop processor it's really 3 hardware cores at 3.2GHz. '6 cores' sounds like a lot, but the important thing to remember is that they are hardware threads and not physical cores. (If curious, the v*128 named instructions are VMX128 - the good news is that they've been documented enough to reverse). The only worrisome area is around the VMX128 instructions, but it turns out there are very few instructions that are unique to VMX128 and most are just the normal Altivec ones.
There are many emulators that have been constructed, some of which run quite fast (or could with a bit of tuning). Luckily there is a tremendous amount of information out there on the PowerPC. This is the biggest potentially scary performance issue, I believe. Operations on registers are fine (a lot of the heavy math where perf really matters), but because of all the clever bit twiddling hacks out there memory must always be valid. PPC has a large register file at 32I/32F/128V relative to x86 at 6I/8F/8V and x86-64 at 12I/16F&V - assuming the PPC compiler is fully utilizing them (or the game developers are, and it's safe to bet they are) this could cause a lot of extra memory swaps.īeing big-endian makes things slightly less elegant, as all loads and stores to memory must take this into account.
General memory accesses on the 360 are fast, but not as fast as the 8MB+ 元 caches commonly found in desktop processors. The shared L2 cache, at 1MB, is fairly small considering there is no 元 cache. Optimizing compilers can only do so much, and instruction streams meant for in-order processors should always run faster on out-of-order processors like the x86. Xenon uses in-order execution - great for simple/cheap/power-efficient hardware, but bad for performance. May mean x86-64 only, or letting some other layer do the work if 32-bit compatibility is a must. Emulating 64-bit on 32-bit instruction sets (such as x86) is not only significantly more code but also at least 2x slower. Xenon is 64-bit - meaning that it uses instructions that operate on 64-bit integers. There are some considerations to take into account when translating the instruction set and worrying about performance, highlighted below: Building a translator for PPC to x86-* is a non-trivial piece of work, but not that bad. The PowerPC instruction set is RISC - this is a good thing, as it's got a fairly small set of instructions (relative to x86) - it doesn't make things much easier, though. ~96GFLOPS single-precision, ~58GFLOPS double-precision, ~9.6GFLOPS dot product L1: 32KB instruction/32KB data, L2: 1MB (shared)Įach core has 32 integer, 32 floating-point, and 128 vector registersĪltivec/VMX128 instructions for SIMD floating-point math They'll cover the CPU, GPU, and operating system.Ħ4-bit PowerPC w/ in-order execution and running big-endian The next few posts will investigate each core component of the system and try to answer the two questions above. Although it's not going to be a piece of cake and there are some significant differences that may cause problems, this actually isn't the worst situation. The hardware is all totally custom (CPU/GPU/memory system/etc), but roughly equivalent to mainstream hardware with a 64-bit PPC chip like those shipped in Macs for awhile and an ATI video chipset not too far removed from a desktop card.
The Xbox 360 is an embedded system, geared towards gaming and fairly specialized - but at the end of the day it's derived from the Windows NT kernel and draws with DirectX 9.