4 ms·

> (ARM has 16. So does x86-64.) 64-bit ARM has 32 GPRs. > Fixed-length instructions instead of variable-length. This is the big legacy of RISC that helps "RI

> (ARM has 16. So does x86-64.) 64-bit ARM has 32 GPRs. > Fixed-length instructions instead of variable-length. This is the big legacy of RISC that helps "RISC" cpus most against x86. M1 has 8-wide decode, with very few stages and low power consumption. Nothing like it can be done for an x86 cpu. The way modern x86 handles this is typically with a uop cache. But this costs a lot of power, area and only provides full decode width for a relatively small pool of insns -- 4k on modern Zen, for example. > > One of the key ideas of RISC was to push a lot of heavy lifting over to the compiler. That is still the case. Micro-ops cannot be re-arranged by the compiler for optimal execution. > Modern compilers do use instruction scheduling to optimize execution, and instruction scheduling for microcoded execution is well-understood. Compiler-level instruction scheduling is mostly irrelevant for modern OoO architectures. Most of the time the CPU is operating from mostly full queues, so it will be doing the scheduling from the past 10-~16 instructions. Compilers are mostly still doing it out of inertia. > "precious silicon" The big difference from that 25 years ago to today is indeed that silicon is now the opposite of precious. We have so many transistors available that we are looking for ways to effectively use more of them, rather than saving precious silicon.

avianes 6y ago
> Nothing like it can be done for an x86 cpu. The way modern x86 handles this is typically with a uop cache. But this costs a lot of power, area and only provides full decode width for a relatively small pool of insns -- 4k on modern Zen, for example. The µOP cache is actually not an explanation of how x86 machines perform the decode, it is rather a way to bypass the decode which is expensive and difficult for them. And the most difficult part is not really the decoding in macro op, the difficulty is to find the boundaries of the instructions to be decoded in parallel. Because the alignment of each instruction to be decoded depends on the size of the previous instructions, this is a sequential process. For example, one way to do this is to use instruction size prediction. Intel and AMD hold several patents related to instruction length prediction [1]. [1]: https://patents.google.com/patent/US20140281246A1/en https://patents.google.com/patent/US20140281246A1/en

avianes 6y ago

> Nothing like it can be done for an x86 cpu. The way modern x86 handles this is typically with a uop cache. But this costs a lot of power, area and only provides full decode width for a relatively small pool of insns -- 4k on modern Zen, for example. The µOP cache is actually not an explanation of how x86 machines perform the decode, it is rather a way to bypass the decode which is expensive and difficult for them. And the most difficult part is not really the decoding in macro op, the difficulty is to find the boundaries of the instructions to be decoded in parallel. Because the alignment of each instruction to be decoded depends on the size of the previous instructions, this is a sequential process. For example, one way to do this is to use instruction size prediction. Intel and AMD hold several patents related to instruction length prediction [1]. [1]: https://patents.google.com/patent/US20140281246A1/en https://patents.google.com/patent/US20140281246A1/en