Cheaper and faster.
Btw, current X86 CPUs are RISC inside with a CISC translation layer. So the Xbox was actually RISC too.
Pentium 1 was the last Intel CISC CPU if I recall right. Pentium Pro was RISC inside with the CISC layer.
RISC versus CISC is a silly argument. The design of cpus is driven by costs and effectiveness, and instruction sets are made more complicated (CISC like) as needed, as evidenced by ARM's 4 different versions of every instruction, and the instruction sets AMD and Intel are always adding to x86.
Small hardware design houses prefer RISC, because it moves the burden to software and reduces hardware design and production costs. The primary advantage of RISC is high clock speeds, which is the most helpful for very simple operations (boolean operations for instance) which can be done in 1 clock cycle in very simple hardware, but in reality a low end CISC cpu with a dedicated multiply hardware could perform a RISC cpu of >3x its clock speed in that specific task. Obviously, a RISC cpu can add in more and more dedicated hardware, but it becomes less RISC like with every addition in hardware.
But even then, current cpus are not truly CISC or RISC. The primary difference between the 'CISC' and 'RISC' cpus is whether or not it's a load-store architecture. Basically all RISC cpus operate directly on registers, and have to perform separate operations to explicitly move data to or from memory. This makes it easier to make compile time and just in time optimizations, because the state of the registers are known, while the state of memory is not, you can optimize code without worrying about the cost of hitting memory and you know exactly how long instructions will take to finish executing, allowing for better scheduling.
A traditional CISC architecture can operate directly on data on the stack. The benefit of this is smaller code size (ie, better use of memory and cache) because you can have implicit arguments to functions and thus smaller instructions. X86 was designed around a world where memory and cache were very expensive, which is why it has variable length instruction decoding. ARM also implemented variable instruction lengths for the same reason, but it has to explicitly switch modes to do so and can't interleave code of different lengths. I hear the vast majority of mobile ARM code these days is done using its 16 bit (or is it 8 bit?) THUMB mode though, since simple operations don't need a full 32-bits, and ARM achieves code density almost on par with x86 because of this. This is very important on mobile platforms, where caches and memory bandwidth are both small.
Oh, and consoles go 'RISC' because almost all cpu designs these days are risc, and they are willing to license their designs for far cheaper than intel would be. Most cpu designs are RISC, because it's harder to design a high performance CISC cpu and the associated compilers. It's practical a miracle that Intel has Atom performing as well as it does, given that it's an in-order CISC cpu.
I remember reading that the use of x86 for the original xbox was to allow a much shorter time to market than any other option would allow for.
This is probably true, the xbox went from announcement to release in like under a year, and it used mostly off the shelf components. Plus, it was a WinNT kernel and microsoft's development tools, which were all x86 focused at the time, MS didn't really have another option.
Although the Intel cpu (something between a Celeron and a then current gen Pentium 3, I believe it was actually the mobile version of the Pentium 3) was a last minute switch, originally the xbox was going to use an AMD Duron cpu (roughly equal in performance to a Pentium 3 per mhz, but it was going to be clocked a bit higher). At the same time, AMD had taken a bunch of marketshare from Intel due to Compaq going heavy on AMD cpus, so Intel was willing to dump their excess on Microsoft at incredibly low cost to get rid of the old supply and also to keep AMD out of the console.
Facebook
Twitter