[SOLVED] Can you use a Raspberry Pi Zero to offload x86 to RISC processing and what performance would that yield?

joshua123033

Honorable
Dec 12, 2018
88
1
10,545
I found this link on Reddit (View: https://www.reddit.com/r/FPGA/comments/6oie3e/hardwarebased_instruction_translation_similar_to/
) but the only problems are latency. But that could be from using an FPGA (according to user tmadness, FPGAs have a low IPC, making them slow). Also, user fatangaboo said that Transmeta tried to do x86 on the fly. But back then ARM processors were slow.

So, since the processing speed of ARM processors have improved, can I use a Raspberry Pi Zero to offload the processing power used in converting x86 code to RISC. Also, what performance improvements could I see (e.g. could an average quad core ARM Cortex be better than an Atom?).
 
Solution
If you want to run x86 code on ARM, the best way is to use a recompiler that reads x86 code and translates it to the ARM equivalent - that's how high-performance emulators work.

If you are going to hijack the ARM instruction decoder to do x86 "conversion" in an FPGA and spit the results back at the ARM to process, you'll have to do practically all the instruction decoding, dependency checking, flag setting, etc. in the FPGA at which point you'd be better off coding a whole x86 CPU in the FPGA instead.
Go to college. Study computer engineering for five years. Work another five years in the field. Then you'll know the answer.

In other words: Modern CPUs are highly integrated devices. There's no way to "insert" RPiZ into the CPU' pipeline (operating at GHz frequency), to offload it from whatever work it's doing.
 
If you want to run x86 code on ARM, the best way is to use a recompiler that reads x86 code and translates it to the ARM equivalent - that's how high-performance emulators work.

If you are going to hijack the ARM instruction decoder to do x86 "conversion" in an FPGA and spit the results back at the ARM to process, you'll have to do practically all the instruction decoding, dependency checking, flag setting, etc. in the FPGA at which point you'd be better off coding a whole x86 CPU in the FPGA instead.
 
Solution