[smaudet]

See the CPU slowdowns and related security issues that resulted from branch prediction, basically CPUs would optimistically assume access and so could be tricked into executing what you wanted...which there was no OS or security level control that could be used to fix that.

https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...

They had to patch "micro code" to turn off the branch prediction in order to fix the security issues, which if they hadn't had that basically a ton of institutions would have been SOL (think banks unable to patch security holes in their computer systems - bodes poorly if you also realize banks aren't usually able to patch their systems overnight).

[chmod775]

While the summary in this reply is at best misleading if not simply wrong, the linked Wikipedia article is good. I recommend just reading that article and disregarding the comment.

Also yes, branch prediction is "a good thing" without which processors wouldn't be able to reach the performance they have today. Starving the whole instructing pipeline at every branch for dozens of cycles is not great.

Even the processor on the BCM2835 used in the first raspberry PI had branch prediction, and for good reason.

[smaudet]

"While the summary in this reply is at best misleading if not simply wrong" - only if you take the summary too literally.

Slow-downs of up to at least 30% did in fact occur (with the older hardware): https://www.techradar.com/news/more-details-emerge-on-how-mu...

As for assuming access and tricking into execution of what you wanted, branching forms the foundation for many if not all OS level security features, in the form of boolean flags, bits behind protected memory (protected by more branching), etc. If the result of a compare causes code to execute that should not (for security reasons), then you have caused execution of what you wanted, which can lead to exposure of e.g. operating system secrets. And with such access it then becomes (sometimes) possible to executing more of what you wanted.

I.e. trusted code could be used to cause insecure results.

Oversimplification, sure, but the truth (exposure of register results due to fault of the hardware) is overly technical and under-emphasizes the severity of the issue, so it is somewhat intentionally misleading...