Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xbox 360 Architecture

copetti.org

Post reply on HN
Print view View original

31–40 of 67 posts

Re: Xbox 360 Architecture

#31

Post by torginus »

javagram wrote: post #25
torginus wrote: post #23

I wonder how true this rumor is, but I remember reading that around the time the F35's computer system was designed, Lockheed Martin shopped around for CPUs from different vendors. PowerPC was a very popular architecture used in military hardware, so LM contracted IBM to design a CPU for them. In Aerospace applications, it's very popular to have triple-redundant system, that's why IBM designed an unusual 3-core Power…

FWIW, the Xbox 360 chip was based on the processor developed for the PS3. No mention of F-35 here. “These cores are slightly modified versions of the PPE in the Cell processor used on the PlayStation 3” https://en.m.wikipedia.org/wiki/Xenon_(processor)

Still, nothing would've prevented IBM from using the Cell PPE as the basis for a PowerPC chip for the military, so that doesn't disprove the theory.

Re: Xbox 360 Architecture

#32

Post by lgunsch »

Working with the ESP32 is what introduced me to the concept of eFuses. Really neat. Allows you to run encrypted firmware images which cannot be easily decrypted even with full physical access to the hardware.

Re: Xbox 360 Architecture

#33

Post by monocasa »

bluedino wrote: post #14
john567 wrote: post #3

This thing branched horribly. You had to use instructions to selectively write to distinct memory locations to avoid typical branching because misprediction was expensive. This was Frostbite/Battlefield 3 era. Good Times.

Is that a POWER thing or what was the main cause?

The xenon core was a slightly modified cell ppe, where there it was focused on saving gates for the cores needed for system management versus more spus.

The idea using it in xenon without the spus was that high perf code could be tailored specifically for this core's uarch being a console, so the in order nature wasn't the worst thing and the gate savings are pretty huge.

Re: Xbox 360 Architecture

#34

Post by monocasa »

torginus wrote: post #31
javagram wrote: post #25

Earlier quoted context omitted.

FWIW, the Xbox 360 chip was based on the processor developed for the PS3. No mention of F-35 here. “These cores are slightly modified versions of the PPE in the Cell processor used on the PlayStation 3” https://en.m.wikipedia.org/wiki/Xenon_(processor)

Still, nothing would've prevented IBM from using the Cell PPE as the basis for a PowerPC chip for the military, so that doesn't disprove the theory.

I know that the Xenon was being simultaneously taped out with the Cell PPE, so it doesn't derive from another cell derived core.

The book "The Race for a New Game Machine" goes over the timing pretty well.

Re: Xbox 360 Architecture

#35

Post by flipacholas »

landr0id wrote: post #29

Super minor nitpick but ROP wasn’t used for the King Kong/SMC exploit. I would consider it a ROP exploit if multiple return-oriented gadgets were chained together to form a full exploit chain, but what happened here is the syscall handler was invoked with a malformed index causing a single jump to user-mode code with kernel-mode privileges. It’s not too dissimilar to calling an arbitrary function pointer. Otherwise t…

No nitpick is too small or too big :) I've just logged your comment on the repo (https://github.com/flipacholas/Architecture-of-consoles/issu...) so I remember to take a look at it after I get back home.

Re: Xbox 360 Architecture

#36

Post by gwern »

flipacholas wrote: post #2

Hi Hackernews, don't forget you can use the alternative edition without styles: https://classic.copetti.org/writings/consoles/xbox-360/ (works better with accessibility tools, like text to speech; and translators) There are also new PDF and EPUB editions here: https://www.patreon.com/posts/67035520 (it's a public post, I just needed a place to upload those files without consuming my hosting's bandwidth). If you spot…

One obvious thing you could do to conserve bandwidth is not do loading=auto but loading=lazy. You've got like 70 images in there which are going to download, but how many readers will scroll to the bottom and look at all 70? (Few.)

Re: Xbox 360 Architecture

#37

Post by bee_rider »

bombcar wrote: post #21
corysama wrote: post #17

Earlier quoted context omitted.

On top of being power architecture, both the 360 and the PS3 chose to push the 4 GHz clock limit before everyone else. To do this they sacrificed lots of speculative and out of order execution features of the CPU. The thinking of the hardware engineers was that the software is compiled for a fixed architecture doing a fixed job so the compiler should be able to statically order the instructions to make the best use o…

The "compiler will solve everything" theory seemed to last quite a long time, I first heard it with the Itanium and again with these pipelined CPUs. Narrator: It didn't solve anything.

This is speculation, but: optimizing compilers are pretty good, right? On x86 at least.

Perhaps they do a good job on popular platforms like x86, because we can encode decades of experience, but not so great on brand new ones.

Re: Xbox 360 Architecture

#38

Post by Veliladon »

bee_rider wrote: post #37
bombcar wrote: post #21

Earlier quoted context omitted.

The "compiler will solve everything" theory seemed to last quite a long time, I first heard it with the Itanium and again with these pipelined CPUs. Narrator: It didn't solve anything.

This is speculation, but: optimizing compilers are pretty good, right? On x86 at least. Perhaps they do a good job on popular platforms like x86, because we can encode decades of experience, but not so great on brand new ones.

One thing that Intel and AMD do better than any other player in the industry is branch prediction. An absolutely stupifying amount of die area is dedicated to it on x86. Combining this with massive speculative execution resources and you can get decent ILP even out of code that's ridiculously hostile to ILP.

Our modern CPU cores have hundreds of instructions in flight at any one moment because of the depth of OoO execution they go to. You can only go that deep on OoO if you have the branch prediction accurate enough not to choke it.

Re: Xbox 360 Architecture

#39

Post by b8 »

Great read and made me nostalgic. There was also a way to turn a jtag/rgh console in to running dev console stuff. Also the trick where if you moved a dev consoles update file to your dev kit's main directory then it will allow 100% r/w/unsigned code. Modern xbone dev kits require their IP to be allowlisted/brick/turn to a retail if not constantly activated. Though there was the ps4 dev kit trick where you could set the console's clock back to when it was activated to unbrick/unlock it again. I wonder what protections/exploits the ps5 dev kits have.

Re: Xbox 360 Architecture

#40

Post by mhh__ »

bee_rider wrote: post #37
bombcar wrote: post #21

Earlier quoted context omitted.

The "compiler will solve everything" theory seemed to last quite a long time, I first heard it with the Itanium and again with these pipelined CPUs. Narrator: It didn't solve anything.

This is speculation, but: optimizing compilers are pretty good, right? On x86 at least. Perhaps they do a good job on popular platforms like x86, because we can encode decades of experience, but not so great on brand new ones.

They do a good job but the scheduling aspects are really really fuzzy.

LLVM and GCC both have models of out of order pipelines but other than making sure they don't stall the instruction decoder it's really hazy whether they actually do anything.

The processors themselves are designed around the code the compilers emit and vice versa.

Post reply on HN