26 ms·
The decoder is wider than it seems but isn't the throughput lower for those instructions anyway? i.e. different decoders for different instructions complexities
by mhh__ 5y ago
The decoder is wider than it seems but isn't the throughput lower for those instructions anyway? i.e. different decoders for different instructions complexities.
The designs M1 is competing with all have L0s, surely? I guess it could be masked off for a low power design but I would've thought not.
Either way, it's old and ugly, I don't miss it at all even if ARM and friends peripheral story probably isn't as good.
- monocasa 5y ago> The decoder is wider than it seems but isn't the throughput lower for those instructions anyway? i.e. different decoders for different instructions complexities. The short decoders don't typically have issues with mod/rm memory destination fields. It's a little confusing because there's typically at least two uOP formats inside the cores. The decoders generally discussed spit out uOPS that still look fairly x86 in the semantics they encode (2 address, can be RMW, etc.) just wide, but fixed width. But by the time they've made their way to the functional units they've been cracked into more uOPs so AGU, LD, ALU, ST can all go to different ports that can handle that work. > The designs M1 is competing with all have L0s, surely? I guess it could be masked off for a low power design but I would've thought not. Most designs I've seen they're actually most important as a power saving feature. They shine well in microbenchmarking for perf, but not as much for general code. The real win is the clock gating all the i fetch and decode, most of which gets shared with RISC too (think I-TLBs, and Ifetch before decode).