3 ms·
"Speculative execution" is a term-of-art, with a specific meaning. I can serve you a warmed up Hershey's bar, and it is literally "hot chocolate", but it is not
by scott_s 9y ago
"Speculative execution" is a term-of-art, with a specific meaning. I can serve you a warmed up Hershey's bar, and it is literally "hot chocolate", but it is not what anyone would expect from that description. When discussing technical matters, it is important to use the right technical terms - hence why the Meltdown and Spectre authors were so careful.
But more important than the term is that the submitted description explains the Meltdown attack in terms of branch instructions, which is not how it works. A reader of the submitted description will come away with an incorrect understanding of what actually happens.
- akvadrako 9y agoNot really - as I said, any instruction which can theoretically raise an exception is a branch. It isn’t the proper terminology but it gives the right idea.
- scott_s 9y agoIn the domain we’re in, “branch” means a branch instruction. If we used your definition, then any load and store instruction would count as a branch, which is not how people use the term. It gives the wrong idea, exemplified by the fact that the submitted article gets it wrong.
- akvadrako 9y agoIf you aren’t a cpu designer than any split between paths of execution is a branch. It gives the right idea, even if the terminology isn’t precise.
- scott_s 9y agoI'm not a "cpu designer," but I am a computer scientist, and when I say "branch," my colleagues expect that I'm talking about an actual branch instruction.
- akvadrako 9y agoIt is an actual branch - just because it has a special instruction is an implementation detail. In computer science there is no difference between throwing an error and skipping the rest of the instructions in the stack. If you wrote a vm with a cpu simulation you would implement it as a branch.
- tptacek 9y agoThis is not a great hill to die on. There are "exception branch tables" and "interrupt branch tables" to configure the implicit branch taken by (say) an interrupt, which acts like a sort of invisible branch; also, on some architectures, rather than "call" you have, literally, "branch and link". You made the point well above when you pointed out that the code paths don't depend on conditional branches that are predicted and explicitly speculated on. I don't think the rest of the semantics are worth litigating.