3 ms·

> linux developer This goes to show you that the software and digital logic design space is very different, and you should not assume any amount of experience

> linux developer This goes to show you that the software and digital logic design space is very different, and you should not assume any amount of experience and knowledge in one will prepare you for the realities of the other. Sure it seems astounding that a CPU would speculate not-taken over a static, direct, unconditional branch. Surely no sane logic designer would ever do such a thing! When you realize doing that might require more logic in a downstream stage after fetch and after the branch was decoded, and from there you need more control logic and wires going to other stages and logic to re-steer the pipeline in possibly a different manner or stage than would otherwise be required, and all that requires validation and verification (which can easily become a multiplicative effort), and if doing all of that did not bring you performance gains that outweighed the cost, and if you didn't understand the possible security implication or considered it to also not be worth the cost, then actually it's quite understandable for a reasonable implementation to behave this way. Even the second quote smells a bit like dunning kruger. Everything has bugs or misfeatures, especially with hindsight. Everyone (including Linus and many other kernel developers) thought that the massive speculation capability and correspondingly astounding performance results on privilege domain crossing for Intel CPUs was the duck's nuts back before spectre/meltdown. And they certainly didn't foresee or discover the security issues with doing that. (EDIT Disclaimer: Am linux developer and armchair microarchitect)

Someone 5y ago
Indeed. If unconditional branches are rare enough it may not be worth the cost. Also, it’s not like software designers don’t waste cycles. In many languages, for example, arguments to log statements are evaluated even if logging is disabled. There sometimes is the hope that the runtime will figure that out and move that inside the if logging is enabled check, but that’s only a hope (COBOL had the ALTER statement for efficiently handling such things, but that’s being frowned upon :-)) Also: a conditional branch can be always taken, for example when the software does an if cpu supports instruction extension at startup, sets a flag accordingly, and later branches depending on that flag. That, too, is a case where the CPU will speculatively execute what, to it, may look like garbage. So, you have to make sure speculative execution handles that.
- throwawaylinux 5y ago
  Yep. Unconditional branches require BTB entries anyway if they're to be predicted ahead of decode, and if AMD's BTB was large and accurate enough then the incremental performance advantage of detecting not-taken direct branches after decode might not have been worthwhile. Security, sure arguably it could have been caught there. But Linux kernel development does not have the high ground when it comes to security problems.

Someone 5y ago

Indeed. If unconditional branches are rare enough it may not be worth the cost. Also, it’s not like software designers don’t waste cycles. In many languages, for example, arguments to log statements are evaluated even if logging is disabled. There sometimes is the hope that the runtime will figure that out and move that inside the if logging is enabled check, but that’s only a hope (COBOL had the ALTER statement for efficiently handling such things, but that’s being frowned upon :-)) Also: a conditional branch can be always taken, for example when the software does an if cpu supports instruction extension at startup, sets a flag accordingly, and later branches depending on that flag. That, too, is a case where the CPU will speculatively execute what, to it, may look like garbage. So, you have to make sure speculative execution handles that.

throwawaylinux 5y ago
Yep. Unconditional branches require BTB entries anyway if they're to be predicted ahead of decode, and if AMD's BTB was large and accurate enough then the incremental performance advantage of detecting not-taken direct branches after decode might not have been worthwhile. Security, sure arguably it could have been caught there. But Linux kernel development does not have the high ground when it comes to security problems.