3 ms·

> Is x86 at the end of the road? No. AMD and Intel are the oligopolistic providers for an unbelievably vast software ecosystem that practically rules all compu

by jabl 4y ago

> Is x86 at the end of the road? No. AMD and Intel are the oligopolistic providers for an unbelievably vast software ecosystem that practically rules all computing outside embedded (and some legacy mainframes here and there), are they going to throw away that market position just because the cleaner encoding of ARM or RISC-V would save an estimated low single-digit % of decoding power [1]? [1]: https://www.usenix.org/system/files/conference/cooldc16/cooldc16-paper-hirki.pdf https://www.usenix.org/system/files/conference/cooldc16/cool...

dmitrygr 4y ago
Top of the line x86 decoders are 6 wide (with limits of 64 aligned bytes on input, making average throughout around 4 per cycle as admitted by intel in their docs). Aarch64 can be decoded as wide as you wish thanks to fixed size. No solution to this other than a fixed length encoding.
- jabl 4y ago
  > No solution to this other than a fixed length encoding. Micro-op caching enters the room. I mean, seriously, micro-op caching has been extensively used for over 20 years, including on ARM64 designs although Apple M1 doesn't have it.
- snvzz 4y ago
  >No solution to this other than a fixed length encoding. This problem does not apply to RISC-V, where with the C extension you get either 32bit or 2x 16bit. The added complexity is negligible, to the point where if a chip has any cache or rom in it, using C becomes a net benefit in area and power. ARMv8 AArch64 made a critical mistake in adopting a fixed 32bit opcode size. A mistake we can see in practice when looking at the L1 cache size that Apple M1 needed to compensate for poor code density. L1 is never free. It is always very costly: Its size dictates area the cache takes, the latency of this cache, the clocks the cache itself can achieve (which in turns caps the speed of the CPU), and how much power the cache draws. As you mentioned decoder width: There's Ascalon[0], a RISC-V microarchitecture that's 8-decode (like M1), and 10-issue, by Jim Keller's team at Tenstorrent. It isn't in the market yet, but is bound to be among the first RISC-V chips targeting very high performance. Note that, at that size (8-decode implies lots of execution units, a relatively large design), the negligible overhead of C extension is invisible. There's only gains to be had. C extension decode overhead would only apply in the comically impractical scenario of a core that has neither L1 Cache nor any ROM in the chip. Such a specialized chip would simply not implement C. Otherwise, it is a net win. 0. https://youtu.be/yHrdEcsr9V0?t=346 https://youtu.be/yHrdEcsr9V0?t=346

by jabl 4y ago

dmitrygr 4y ago

Top of the line x86 decoders are 6 wide (with limits of 64 aligned bytes on input, making average throughout around 4 per cycle as admitted by intel in their docs). Aarch64 can be decoded as wide as you wish thanks to fixed size. No solution to this other than a fixed length encoding.

jabl 4y ago
> No solution to this other than a fixed length encoding. Micro-op caching enters the room. I mean, seriously, micro-op caching has been extensively used for over 20 years, including on ARM64 designs although Apple M1 doesn't have it.
snvzz 4y ago
>No solution to this other than a fixed length encoding. This problem does not apply to RISC-V, where with the C extension you get either 32bit or 2x 16bit. The added complexity is negligible, to the point where if a chip has any cache or rom in it, using C becomes a net benefit in area and power. ARMv8 AArch64 made a critical mistake in adopting a fixed 32bit opcode size. A mistake we can see in practice when looking at the L1 cache size that Apple M1 needed to compensate for poor code density. L1 is never free. It is always very costly: Its size dictates area the cache takes, the latency of this cache, the clocks the cache itself can achieve (which in turns caps the speed of the CPU), and how much power the cache draws. As you mentioned decoder width: There's Ascalon[0], a RISC-V microarchitecture that's 8-decode (like M1), and 10-issue, by Jim Keller's team at Tenstorrent. It isn't in the market yet, but is bound to be among the first RISC-V chips targeting very high performance. Note that, at that size (8-decode implies lots of execution units, a relatively large design), the negligible overhead of C extension is invisible. There's only gains to be had. C extension decode overhead would only apply in the comically impractical scenario of a core that has neither L1 Cache nor any ROM in the chip. Such a specialized chip would simply not implement C. Otherwise, it is a net win. 0. https://youtu.be/yHrdEcsr9V0?t=346 https://youtu.be/yHrdEcsr9V0?t=346