6 ms·
Another win for ARM! Glad to see the industry finally pivoting to RISC. I also wonder if this will integrate with Fuschia?
by uncomputation 5y ago
Another win for ARM! Glad to see the industry finally pivoting to RISC. I also wonder if this will integrate with Fuschia?
- 1-more 5y agoYah, RISC is good https://www.youtube.com/watch?v=RL9yCWv7NS0 https://www.youtube.com/watch?v=RL9yCWv7NS0
- kevin_thibedeau 5y agoThey pivoted 25 years ago with Pentium Pro.
- mhh__ 5y agoStill has a phat decoder on the front, consuming power all the time + I don't want a disassembler to be a PhD project like it is for x86 with all its extensions and prefixes (and suffix?)
- monocasa 5y agoIn designs with a L0 uOP cache, they clock gate the decoder when just running out of L0. But it's really not that much power compared to a giant ROB and bypass network in these newer designs. And they don't really have suffixes in x86.
- mhh__ 5y agoHence the question mark, wasn't it 3DNow! The fact that it has a to have a big streaming cache just for the decoding puts it at a loss. Intel have only just gone 6 wide. Is it the end of the world? No. Do I want a RISC machine? Yes
- monocasa 5y ago3Dnow used an immediate field for an extended opcode, but you still figured out the length of the instruction from looking at the first opcode bytes, so it's not really a suffix. As far as the decoder was concerned, it was just another fixed length, required imm field for the execution unit. It doesn't have to have a L0 cache; a lot of designs don't. And the decoder is wider than it seems. x86 instructions have more uOPs mainly from RMW instructions that would be three separate instructions in RISC. It'll be fun to compare Zen 4 (even at Ultrabook TDP) and M1 apples to apples once everyone has access to 5nm.
- mhh__ 5y agoThe 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).
- kevin_thibedeau 5y agoARM Cortex chips have a decoder on the front. It's no different.
- mhh__ 5y agoARM Cortex has a pistol, X86 has a howitzer comparatively. The observation that ARM also uses a decoder is not a useful one.