Last month, a team of Google security researchers released a tool that can modify microcode of AMD's processors based on the Zen microarchitecture, the Zentool. While this is a security vulnerability, for some, this is an opportunity; Members of the Chinese Jiachen Project are running a contest with an aim to develop a microcode for AMD's modern Zen-based CPU to make them execute RISC-V programs natively. The ultimate goal could be building an ultimate RISC-V CPU using already available silicon.
x86 is a complex instruction set computer (CISC) instruction set architecture (ISA) developed some 48 years ago. However, internally, modern x86 cores rely on proprietary engines running a reduced instruction set computer (RISC) ISA to handle complicated instructions. The internal RISC ISAs are not documented, but they should generally be similar to well-known RISC ISAs, such as Arm or RISC-V. CPU microcode is a low-level layer that translates complex x86 CISC instructions into simple RISC-like internal instructions the CPU hardware executes. CPU microcode is only supposed be modifiable by CPU vendor, but sometimes this is not the case and apparently some parts of AMD's Zen 1/2/3/4 microcode can be changed using the Zentool.
The Jianchen Project members want to find someone, who can modify AMD's Zen CPU microcode on a modern processor — say, an EPYC 9004-series — to execute RISC-V binaries. The patch is expected to either enable direct execution of RISC-V programs or significantly boost their runtime speed compared to emulation using the same hardware. The work must be tested using RISC-V versions of benchmarks like Coremark or Dhrystone. A complete submission includes binaries or source code, configuration files, dependencies, and test instructions. If only binaries are submitted before the deadline on June 6, identical source code must be added via pull request later. The winner will get ¥20,000 (approximately $2,735).
AMD's EPYC 9004-series and similar processors offer performance and core counts not achievable on currently available RISC-V-based processors, so executing proprietary RISC-V programs on EPYCs is a plausible idea. However, microcode is designed to fix internal bugs rather than replace the front-end ISA completely and it is even unclear whether the microcode can be completely re-written, people over at Ycombinator noted.
Back in the mid-2010s, AMD planned to offer both x86-64 and Armv8-A Zen CPUs (something recently recalled by Mike Clarke, AMD's chief architect), so it is highly likely that there was a microcode for the Zen 1 microarchitecture that supported an Aarch64 front-end ISA. That said, Zen 1 CPUs could feature multiple microcode layer 'slots,' one supporting x86-64 and another Aarch64. We doubt this is the case though as modern CPUs have very thorough hardware performance optimizations that include hardwire optimizations between the microcode and the rest of the core. AMD has hardly ever developed a microcode that supports Aarch64 or RISC-V for Zen 2/3/4 processors and therefore the microcode layer of these CPUs is strictly x86-64 and there is hardly enough microcode space for re-writing them from scratch.
"This is not achievable," one commenter named Monocasa wrote. "There is not enough rewritable microcode to do this even as a super slow hack. And even if all of the microcode were rewritable, microcode is kind of a fallback pathway on modern x86 cores with the fast path being hardwired decode for x86 instructions. And even if that were not the case the microcode decode and jump is itself hardwired for x86 instruction formats. And even if that were not the case the micro-ops are very non-RISC."
One commenter criticized the contest format, suggesting it is a way to get complex work done for less than $3,000 pay.
In general, while the concept of re-writable microcode is an interesting one and stimulates discussion about alternative CPU designs, multi-ISA support, and low-level optimization, it does not look like the contest will achieve the stated goal. Perhaps, re-writing (or rather re-compiling) a RISC-V program or two for x86 CPUs makes more sense?
