News Google tool spurs contest to Run RISC-V on AMD Zen CPUs: But is it possible?

[Admin]

A new contest inspired by Google's Zentool challenges developers to modify AMD Zen CPU microcode to run RISC-V programs natively, but experts argue the goal is unfeasible.

Google tool spurs contest to Run RISC-V on AMD Zen CPUs: But is it possible? : Read more

 

[bit_user]

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.

First of all, I just want to point out that this contest was linked in a prior article:

https://www.tomshardware.com/pc-com...dge-turin-ryzen-ai-300-and-fire-range-at-risk
​

As with that article, you linked the Chinese language version of the page. At the top, there's a way to switch it to English, which I'll link here:

https://rvspoc.org/en/S2502/?persistLocale=true
​

And, as I commented on that article, what the contest actually says is:

"Complete microcode modifications for Zen-series CPUs to enable direct execution of RISC-V binary programs. If direct execution is not feasible, optimize the modified microcode to achieve a significant level of acceleration for RISC-V binaries."
​

So, they're not asserting that it's indeed possible (which I doubt), but leaving open the possibility that contestants can at least devise some microcode tweaks that improve the efficiency of RISC-V emulation or JIT execution.

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

There's been some reverse-engineering work done. For those who know a little about assembly language and want to get a rough idea what the micro-ops look like, start here:

https://github.com/google/security-...pocs/cpus/entrysign/zentool/docs/reference.md
​

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.

They should really focus on Zen 5, exclusively. It has 3x the microcode table size, which will almost certainly be necessary for the more interesting and profitable hacks. Note the author ( 😉 ):

https://www.tomshardware.com/news/amd-set-to-substantially-increase-microcode-size-of-future-cpus
​

Back in the mid-2010s, AMD planned to offer both x86-64 and Armv8-A Zen CPUs

The ARM core, based on Zen, was internally called the K12. It's the last thing Jim Keller was known to work on, before he left AMD (for the second time).

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.

Not likely. Everything that's come out about it suggests it was a distinct core, just that it differed mostly in the front-end.

There have been CPUs which did some sort of realtime translation/emulation. I think Transmeta was one example. I seem to recall that Itanium also had some sort of x86 mode, which I believe involved some kind of hardware-assisted emulation. However, the resulting performance was quite lackluster, I'm sure mostly owing to the limitations of IA64.

One commenter criticized the contest format, suggesting it is a way to get complex work done for less than $3,000 pay.

Yeah, my thought was that they'd do better by getting people to collaborate. However, the contest certainly sparked interest and garnered attention. Maybe they'll try to combine some of the best ideas from contest entrants into an open source project, afterwards, and welcome contestants to stay involved.

it does not look like the contest will achieve the stated goal.

The real goal is just to increase RISC-V execution performance. Whether you can achieve native execution or not is sort of a detail. A secondary benefit (not sure if it's actually a goal) is to crowd-source reverse engineering of AMD's micro-op language, which should shed further insight into the microarchitecture of their CPUs.

I think a fruitful example of the sort of thing that might improve RISC-V emulation is this hack Apple made to the ARM ISA, in order to facilitate faster x86 emulation:

Why is Rosetta 2 fast?

Rosetta 2 is remarkably fast when compared to other x86-on-ARM emulators. I’ve spent a little time looking at how it works, out of idle curiosity, and found it to be quite unusual, so I figur…

dougallj.wordpress.com

 

[ezst036]

Why not re-write the code for x86 CPUs?

x86 is the long-awaited successor for RISC-V.

 

[mtrantalainen]

A new contest inspired by Google's Zentool challenges developers to modify AMD Zen CPU microcode to run RISC-V programs natively, but experts argue the goal is unfeasible.

Google tool spurs contest to Run RISC-V on AMD Zen CPUs: But is it possible? : Read more

The offered prize money (less than $3000) is way to little for this complex task.

I think you could realistically see some submissions if you increase the prize 100-fold.

 

[ThereAndBackAgain]

One question: why? Is the idea to make the development of RISC-V apps easier? Surely it's not to satisfy the great demand for being able to run all the many exclusively-RISC-V apps on X86? Or is this more a "because it's there/because we can" type of venture?

 

[bit_user]

The offered prize money (less than $3000) is way to little for this complex task.

Right. You wouldn't do it just for that. I think it's enough to draw in people who are naturally interested in hacking on it and getting them to actually make a formal submission.

Let's see what kinds of entries they get.

 

[bit_user]

One question: why? Is the idea to make the development of RISC-V apps easier?

There are a lot of AMD CPUs out there that are vulnerable to this exploit. Right now, I believe most RISC-V development does happen using emulators. So, the upside to making those emulators faster is definitely real.

As I said, another benefit is crowd-sourced reverse-engineering & documentation of AMD's internal micro-ops. You can probably imagine various uses such information might have.

Surely it's not to satisfy the great demand for being able to run all the many exclusively-RISC-V apps on X86?

Several major Linux distros already support RISC-V and their CI pipelines currently rely on emulators running on x86 and ARM servers, because how else do you bootstrap something like that before we even have big iron RISC-V CPUs?

 

[rluker5]

There have been CPUs which did some sort of realtime translation/emulation. I think Transmeta was one example. I seem to recall that Itanium also had some sort of x86 mode, which I believe involved some kind of hardware-assisted emulation. However, the resulting performance was quite lackluster, I'm sure mostly owing to the limitations of IA64.

The real goal is just to increase RISC-V execution performance. Whether you can achieve native execution or not is sort of a detail. A secondary benefit (not sure if it's actually a goal) is to crowd-source reverse engineering of AMD's micro-op language, which should shed further insight into the microarchitecture of their CPUs.

I think a fruitful example of the sort of thing that might improve RISC-V emulation is this hack Apple made to the ARM ISA, in order to facilitate faster x86 emulation:

​

Why is Rosetta 2 fast?

Rosetta 2 is remarkably fast when compared to other x86-on-ARM emulators. I’ve spent a little time looking at how it works, out of idle curiosity, and found it to be quite unusual, so I figur…

dougallj.wordpress.com

​

Another example of CPUs that did realtime emulation/translation (of x86 to ARM) are the decade old atom chips that ran native android in the Asus Zenfone 2 and Leagoo T5C.

Those chips did not perform badly at the time and have pathetic performance by modern standards. (The Z3775 in my old windows tablet gets 47 single/ 178 multi in CPU-Z and is a slightly faster version of the Z3580 found in the Zenfone 2). I don't know how much faster ARM chips have gotten over the last decade, but Zen5 is almost 20x as fast in single core as these old Atom chips. If ARM hasn't increased single core performance by an order of magnitude maybe there is something to be gained. But if ARM chips have, then running RISC-V on x86 is probably a stopgap at best.

 

[bit_user]

Another example of CPUs that did realtime emulation/translation (of x86 to ARM) are the decade old atom chips that ran native android in the Asus Zenfone 2 and Leagoo T5C.

I don't know if they had/used an ARM emulator in those phones, but it wasn't hardware-based, which is what I was talking about.

Android was originally (and I think still predominantly) Java-based. Java is compiled to a portable byte code, which is then JIT-compiled to run on your native architecture (either at runtime or I think Android does it when you install the app). This JIT-compilation scheme has been the norm for several decades, if not all the way back in the 90's.

Java used bytecode since the beginning, with portability across different CPU ISAs being the main goal - it was developed by Sun Microsystems, who had their own RISC CPUs, but positioned as a web standard that would enable browser-based applets to run on Macs, PCs, Sun workstations, etc. It was even incorporated into the blu-ray standard, for this very reason.

Android does allow apps to bundle some native code, but it's fairly rare for them to do so. It's mostly just used by things like game engines. The Android NDK has support for compiling to multiple targets, including x86. So, even if an app included some native code, it could bundle an ARMv7, ARMv8, and x86-64 version of that code.

 

[mikeztm]

I don't know if they had/used an ARM emulator in those phones, but it wasn't hardware-based, which is what I was talking about.

Android was originally (and I think still predominantly) Java-based. Java is compiled to a portable byte code, which is then JIT-compiled to run on your native architecture (either at runtime or I think Android does it when you install the app). This JIT-compilation scheme has been the norm for several decades, if not all the way back in the 90's.

Java used bytecode since the beginning, with portability across different CPU ISAs being the main goal - it was developed by Sun Microsystems, who had their own RISC CPUs, but positioned as a web standard that would enable browser-based applets to run on Macs, PCs, Sun workstations, etc. It was even incorporated into the blu-ray standard, for this very reason.

Android does allow apps to bundle some native code, but it's fairly rare for them to do so. It's mostly just used by things like game engines. The Android NDK has support for compiling to multiple targets, including x86. So, even if an app included some native code, it could bundle an ARMv7, ARMv8, and x86-64 version of that code.

It’s quite common for android app to have native components. For security reasons more so than performance reasons.

And back in the day armv7 was the only meaningful target from the then 2 available Armv7 and MISP. Intel have to bundle the code named Medfield arm translator to run those armv7 native binaries.

Medfield is pure software based and can run on any then modern Intel and AMD processors. It was included in a lot of “Android emulator” software including bluestack.

 

[bit_user]

It’s quite common for android app to have native components. For security reasons more so than performance reasons.

And back in the day armv7 was the only meaningful target from the then 2 available Armv7 and MISP. Intel have to bundle the code named Medfield arm translator to run those armv7 native binaries.

Medfield is pure software based and can run on any then modern Intel and AMD processors. It was included in a lot of “Android emulator” software including bluestack.

Medfield was the name of Intel's phone SoC, not the ARM -> x86 binary translator.

However, thanks for the mention. It helped me find this description, from which I quote:

"The OS isn't an issue as it has already been ported to x86 and all further releases will be available in both ARM and x86 flavors. The bigger problem is application compatibility.

There's already support for targeting both ARM and x86 architectures in the Android NDK so anything developed going forward should be ok so long as the developer is aware of x86.

Obviously the first party apps already work on x86, but what about those in the Market?

By default all Android apps run in a VM and are thus processor architecture agnostic. As long as the apps are calling Android libraries that aren't native ARM there, once again, shouldn't be a problem. Where Intel will have a problem is with apps that do call native libraries or apps that are ARM native (e.g. virtually anything CPU intensive like a 3D game).

Intel believes that roughly 75% of all Android apps in the Market don't feature any native ARM code. The remaining 25% are the issue. The presumption is that eventually this will be a non-issue (described above), but what do users of the first x86 Android phones do? Two words: binary translation."

... by intercepting ARM binaries and translating ARM code to x86 code on the fly during execution Intel is hoping to achieve ~90% app compatibility at launch."

Source: https://www.anandtech.com/show/5365/intels-medfield-atom-z2460-arrive-for-smartphones/5
​

 

[rluker5]

I don't know if they had/used an ARM emulator in those phones, but it wasn't hardware-based, which is what I was talking about.

Android was originally (and I think still predominantly) Java-based. Java is compiled to a portable byte code, which is then JIT-compiled to run on your native architecture (either at runtime or I think Android does it when you install the app). This JIT-compilation scheme has been the norm for several decades, if not all the way back in the 90's.

Java used bytecode since the beginning, with portability across different CPU ISAs being the main goal - it was developed by Sun Microsystems, who had their own RISC CPUs, but positioned as a web standard that would enable browser-based applets to run on Macs, PCs, Sun workstations, etc. It was even incorporated into the blu-ray standard, for this very reason.

Android does allow apps to bundle some native code, but it's fairly rare for them to do so. It's mostly just used by things like game engines. The Android NDK has support for compiling to multiple targets, including x86. So, even if an app included some native code, it could bundle an ARMv7, ARMv8, and x86-64 version of that code.

After looking into it more it seems you are right: https://www.android-x86.org/
I don't know how much of what I've run on my Leagoo T5c is translated but I do know some things run relatively poorly while most run well (compared to similar hardware running Windows). But I don't get any special apps from the play store. They are the same as what the ARM chips get. Some issues may be from running an old phone that didn't have good graphics at the time on Android 7 though. That and I haven't wasted a lot of time playing with random apps on an old phone I stopped using long ago because AT&T type towers have terrible data reception in my area compared to Verizon type so there may be issues with a lot of apps that I haven't tried.

 

[mocenigo]

This looks like a task for Arrigo Triulzi: https://troopers.de/events/troopers16/655_the_chimaera_processor/

 

[bit_user]

This looks like a task for Arrigo Triulzi: https://troopers.de/events/troopers16/655_the_chimaera_processor/

That's insane, if they actually did it!

In this talk we describe a new processor design which builds upon previous work on modifying microcode on several cores within a processor to obtain a “new” processor.
​

The word "describe" seems a little suspicious, to me. And all I see is a rough overview of the talk. Is there a video or slides for it?

P.S. although an amazing hack, that CPU wouldn't be very practical. In order to make it work as described, they'd have to do a lot of things that slow it way down. As I understand it, the true goal of this contest is not native RISC-V execution, but accelerated emulation.

AFAIK, whenever microcode gets involved, there's an inherent performance penalty. That's before the microcode has even done its thing. So, whatever microcode mods you do, they need to pull their weight. That means probably just focusing on papering over the bigger impedance mismatches between the ISAs.