Paul A. Clayton (paaronclayton.delete@this.gmail.com) on July 31, 2022 3:20 pm wrote:
>
> While such ISA compatibility has significant benefits, I suspect AVX-512 is expensive to implement in a small
> core because of the large architected state (32 64-byte registers plus mask registers). While a "low performance"
> core would not have to have as much register renaming and would presumably have fewer execution resources, the
> large state still feels burdensome. Some resources could be shared between cores in a Bulldozer-like design.
> Some resources might shared between threads (if multithreading is supported in a low performance core). GPU-style
> wider register access than execution and traditional banking could reduce the port count and thus area, but
> a 8 KiB single-ported register file would still seem to be kind of chunky. With sharing across cores, if AVX-512
> is lightly used by both cores or heavily used by one, the active state could be smaller.
>
> Narrower execution and sharing across threads would tend to reduce
> the need for rename registers by hiding some latency.


While 2 kB is not a small size for the architecturally-visible registers, I cannot believe that this size can cause any serious implementation difficulties in small cores.

Already 40 years ago, there were RISC CPUs with an architectural register file only a few times smaller, e.g. of 512 B, even if they were using millions times less transistors per CPU core.

A modern CPU has more register file ports, but AVX-512 does not need more ports than the ISAs with a smaller register file, because this is one of the main advantages of using wider registers, i.e. that increasing the register width increases the throughput without requiring additional register file ports.


Moreover, all the resources related to register renaming and to any other parts of the CPU control depend on the number of registers, i.e. 32, and not on their width.

32 registers for the FPU, besides the general-purpose registers, have been used in a very large number of CPUs for many decades, most of them being many orders of magnitude less complex than the smallest cores of today, such as Cortex-A510.


So I do not buy the argument that implementing 32 wide registers can cause any difficulties. There are many other features which influence the core complexity much more, and they can be removed from a small core without affecting ISA compatibility and the number and size of the visible registers.


Now that is too late to be changed, but if Intel would have ever believed that the size of the registers matters, it would have been very easy to provide a couple of CPUID bits with the implemented register width, e.g. 128/256/512, allowing the software to use the corresponding AVX-512 subset of instructions, which would have been much better than falling back to AVX.

I think that from their actions (e.g. the backporting of some instructions from AVX-512 encoding to AVX encoding, and earlier of some from AVX encoding to SSE encoding) it results that the main problem with implementing AVX-512 is extending the instruction decoders with the support of another set of encoding formats and not the implementation of more or wider registers.