Both the PS3 and X360 CPUs featured no out of order execution, no speculative execution, no automatic prefetch, and a 500 cycle latency for hitting main mem outside of cache.

The hardware design was based on 1) This is currently the only way to hit that clock rate at this cost 2) Hyperthreading effectively halve all latencies 3) It's a fixed platform, the compiler should know exactly what to do. 3 was pretty laughable. It is only technically possible if you have huge linear code blocks without branching or dynamic addressing.

I would remind junior programmers that the PS2 ran at 300Mhz and had a 50 cycle memory latency and the PS3 ran at 3Ghz but had a 500 cycle latency. So, if you are missing cache, your PS3 game runs like it's on a PS2.

On the other hand, a lot of people overreacted to the manual DMA situation of SPU programming. DMAs from main mem into SPU mem had a latency of.... 500 cycles! Once people put 2 and 2 together, SPU programming became less scary. Still a pain in the ass. And, a lot of work to reach peak performance. But, more approachable for sub-optimal tasks.

Also that damn load hit store penalty. PPEs and Xenon cores could only detect and stall if a read was for an address that was currently being flushed out of the write buffers. Most sane uarchs will bypass out of the store queue, but those cores needed to flush all of the way out to L1 and read it back in.

Also, IIRC, shift by variable amount was microcoded and would take a cycle for each bit distance shifted.

> Also, IIRC, shift by variable amount was microcoded and would take a cycle for each bit distance shifted.

Wait, it was possible to ship a CPU in 2006 without a barrel shifter? ARM1 was from 1985!

If it was something silly like "only constant bit shifts use the barrel shifter", I'm surprised that compilers didn't compile variable shifts as a jump table to a bunch of constant shift instructions... :)

>Wait, it was possible to ship a CPU in 2006 without a barrel shifter? ARM1 was from 1985!

I was absolutely floored too.

And it made very little sense to me either. PowerPC has probably my favorite main ISA bit manipulation instructions out there: rwlimi

https://www.ibm.com/docs/en/aix/7.2?topic=is-rlwimi-rlimi-ro...

Any logical shift, rotate, bit field extract (by constant) and more all in one single cycle instruction that's been included since the earliest POWER days. They had a barrel rotater in the core for that instruction.

The only thing that makes any sense to me is that somehow it would have been too expensive to rig up another register file read port to that sh input, so they just pump it as many times needed with sh fixed to 1. They seemed to be on some gate count crusade that might have payed off if they were able to clock it faster at the end of the day. It took the industry a bit to figure out that ubiquitous 10Ghz chips weren't going to happen, and the hardest lessons would have been right in that design cycle. : \

> If it was something silly like "only constant bit shifts use the barrel shifter", I'm surprised that compilers didn't compile variable shifts as a jump table to a bunch of constant shift instructions... :)

Variable shift isn't the most common op in the world, so as far as I know it was just listed as something to avoid if you're writing tight loops.