Why I’m Leaving PowerPC (For Now) – But I Will Return to Conquer It!

For the past several months, I have waged war against one of the most difficult ISAs in existence: PowerPC. Armed with a deep understanding of RTL design and a stubborn refusal to quit, I set out to build an out-of-order (OOO) PowerPC core with proper branch prediction.

I failed.

Not because of a lack of effort. Not because of a lack of skill. But because PowerPC, as defined by IBM, is full of inconsistent documentation, baffling design choices, and outright missing explanations for critical system behaviors.

The PowerPC Problem: A Symphony of Pain

1. Phantom Instructions & Ghostly Forms

IBM’s documentation includes instruction forms that don’t exist and instructions that correspond to no real format. If you think you can build a decoder by following their spec, you will discover contradictions that force you to guess what the CPU is actually doing.

2. Virtual Memory: Undefined in Mixed-Radix Chaos

The Power ISA attempts to describe virtual memory in a way that conveniently skips over crucial details—particularly in mixed-radix mixed-segment mode. If you’ve ever wondered what happens in this configuration, don’t ask IBM. They probably don’t know either.

3. Side Effects: Scattered Like a Bad ARG

Instead of clearly listing all the effects of an instruction in one place, IBM has chosen to randomly distribute them throughout the manual like hidden lore in an obscure video game.

4. Registers: Manipulating Them Has Unspoken Consequences

Some registers have well-documented behaviors. Others? Good luck finding their full behavior across multiple disjoint sections of the manual. You’ll only know you missed something when your design inexplicably fails.

PowerPC OOO: An Impossible Nightmare?

One of the final straws was trying to design out-of-order execution around PowerPC’s Condition Registers (CRs). Unlike a sane ISA where status flags are handled simply, PowerPC allows partial CR updates(up to 8 in an instruction), multiple reads/writes in a single instruction, and logical CR operations—all of which make dependency tracking and speculative execution a nightmare of biblical proportions.

I tried to implement branch prediction with CR dependencies. I fought through the complexity. But eventually I came to my sense when I began to question my life choices.

The Path Forward: A Formal RISC-V Model

Rather than continue my descent into madness, I’m shifting focus to a new goal: a formal model of RISC-V in Haskell. I will build it cleanly, correctly, and formally prove its execution. Eventually, this will be lowered into a Bluespec Haskell implementation on FPGA.

RISC-V has:

• A sane, well-documented ISA
• No random undocumented side effects
• A modern, scalable design

In short: it’s not PowerPC.

I Will Return to PowerPC – And I Will Win

This is not surrender. This is a strategic retreat. When my RISC-V model is complete, when my FPGA design is running, and when I have fully mastered formal hardware design, I will return to PowerPC.

I will take everything I have learned and build the most painful, formally verified, correctly implemented PowerPC OOO core ever designed. I will fix what IBM failed to document. I will redeem the Power ISA.

Until then, PowerPC remains undefeated. But not forever.

🚀 Onward to RISC-V. PowerPC’s redemption will come.