3 ms·
> having to emulate that through heuristically guessing at instruction boundaries and backtrack when you make a mistake Intel/AMD don't use heuristics-based de
by phire 1y ago
> having to emulate that through heuristically guessing at instruction boundaries and backtrack when you make a mistake
Intel/AMD don't use heuristics-based decoding, or backtracking. They can decode 4 instructions in a single cycle. They implement this by starting a pre-decode at every single byte offset (within 16 bytes) and then resolving it to actual instructions at the end of the cycle.
The actual decode is then done the following cycle, but the pre-decoder has already moved upto 4 instructions forwards, so the whole pipelined decoder can maintain 4 instructions per cycle on some code.
This pre-decode approach does have limits. Due to propagation delays, 4 instructions over 16 bytes is probably the realistic limit that you can push it (while Apple can easily do 8 instructions over 32 bytes). Intel's Golden Cove did finally push it to 6 instructions over 32 bytes, but I'm not sure that's worth it.
Intel's Skymont shows the way forwards. It only uses 3-wide decoders, but it has three of them running in parallel, leapfrogging over each other. They use the branch predictor to start each decoder running at a future instruction boundaries (inserting dummy branches to break up large branchless blocks). Skymont can maintain 9 instructions per cycle, which is more than the 8-wide that Apple currently is using. And unlike the previous "parallel pre-decode in a single cycle", this approach is scalable. Nothing stopping Intel adding a fourth decoder for 12 instructions per cycle, or a fifth decoder for 15. AMD is showing signs of going down the same path, zen5 has two 4-wide decoders though they can't work on the same thread, yet.
- vlovich123 1y agoYou're arguing semantics IMHO. In my mind speculatively decoding every single byte offset & then resolving at the end of the cycle which to take is a form of heuristic execution because the heuristic is "decode all possible executions". And 4 vs 8 is a pretty sizeable difference. Moreover, the pre-decoder requiring knowing the op-codes at the end means all instruction decodes are serialized on decoding 16 instructions whereas Apple can just decode each op independently & only decodes 8.
- phire 1y agoOh, I see what you are saying. I don't consider it to be a heuristic because it's simply bruteforcing it. IMO a heuristic needs improve over brute force. > And 4 vs 8 is a pretty sizeable difference. True, but x86 was doing four instruction 20 years ago. As I mentioned the current state of the art (in a shipping product) is 9, and 9 is larger than 8. Importantly, this Skymont of leapfrogging decoders approach is scalable. > whereas Apple can just decode each op independently & only decodes 8. Apple isn't as free from serialisation as you suggest. Like X86, many instructions decode to multiple uops. According to research [1] instructions which decode to two uops are common and a few decode to as many as 12 uops. It also does instruction fusion, two neighbouring instructions can sometimes decode into a single uop. This all means that there is plenty of serialisation within Apple's decoder. And branching also creates serialisation. It's just not as simple as independently decoding eight instructions into eight uops every cycle. Simpler than what x86 implementations need to do, but not as brain-dead simple as you suggest. Actually, Skymont's approach has an advantage over Apple here, because it only needs to serialise within each 3-wide decoder. [1] https://dougallj.github.io/applecpu/firestorm.html https://dougallj.github.io/applecpu/firestorm.html