[HN Gopher] Felix86: Run x86-64 programs on RISC-V Linux
___________________________________________________________________
Felix86: Run x86-64 programs on RISC-V Linux
Author : rguiscard
Score : 118 points
Date : 2025-05-02 00:07 UTC (22 hours ago)
(HTM) web link (felix86.com)
(TXT) w3m dump (felix86.com)
| badmonster wrote:
| What remaining challenges are you most interested in solving for
| felix86--GPU driver support, full 32-bit compatibility, better
| Wine integration, or something else entirely?
| westurner wrote:
| The felix86 compatibility list also lists SuperTux and
| SuperTuxCart.
|
| "lsteamclient: Add support for ARM64."
| https://github.com/ValveSoftware/Proton/commit/8ff40aad6ef00...
| .. https://news.ycombinator.com/item?id=43847860
|
| /? box86:
| https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
|
| "New box86 v0.3.2 and Box64 v0.2.4 released - RISC-V and WoW64
| support" (2023) https://news.ycombinator.com/item?id=37197074
|
| /? box64 is:pr RISC-V is:closed:
| https://github.com/ptitSeb/box64/pulls?q=is%3Apr+risc-v+is%3...
| JonChesterfield wrote:
| Haven't found the source code
| (https://github.com/orgs/felix86-emu/repositories looked likely
| but no), curious whether this is a qemu fork or a DIY effort.
| drmpeg wrote:
| https://github.com/OFFTKP/felix86/
| JonChesterfield wrote:
| Nice, thanks! I appreciate seeing a bunch of the instruction
| definitions written in a serialisation format (e.g. https://g
| ithub.com/OFFTKP/felix86/blob/master/counts/SSE2.js...) as
| opposed to C macros.
| bonzini wrote:
| Those are tests, it seems. The actual sources are at
| https://github.com/OFFTKP/felix86/tree/master/src/felix86
| and the disassembler is https://zydis.re.
| guerrilla wrote:
| This is good. Maybe it means some day we'll able to run Steam on
| it. Wouldn't that be funny? Windows emulation on x86-64 emulation
| on RISC-V.
| snvzz wrote:
| I am hopeful valve will release a risc-v build themselves.
|
| And wine/proton will integrate with this or some similar
| solution for running x86 binaries.
| guerrilla wrote:
| They can't. The games themselves are compiled for x86-64 and
| closed source. It's not enough if they just recompiled Steam,
| Proton, etc.
| rwmj wrote:
| It seems as if there are unofficial(?) Steam ports to Arm
| which presumably run the x86-64 binaries in emulation, so
| that would be a similar sort of thing.
| OptionX wrote:
| Always wondered why RISC-V doesn't get more mainstream adoption.
|
| Even if not at the consumer level, having your data center, for
| example, running a cheaper (I assume since no license for the
| instruction set means not having to pay for it and more options
| to buy from leading to lower prices) and less power demanding
| option when compared to x86-64 sounds enticing to me.
|
| Maybe no one wants to be the genea pig to iron out the kinks of
| the transition or maybe the raw performance of x86 is bigger deal
| than I think it is and its worth the price and power. Dunno.
| bobmcnamara wrote:
| > Always wondered why RISC-V doesn't get more mainstream
| adoption.
|
| For me, it's because the ecosystem has fragged even harder than
| Xtensa, who will sell you custom CPUs. THead made yet another
| vector unit that's required to approach anything near the
| Intel/AMD moat numbers.
|
| SpecInt/GHz last year was around half of Intel/AMD/ARM numbers.
|
| The imminent demise of CISC has been trumpeted from the
| rooftops for at least the last 30 years...
| deaddodo wrote:
| ARM isn't CISC and has, by sheer numbers, completely
| dominated x86 for decades now; not counting the massive
| number of MIPS, AVR, etc embedded chips.
|
| Additionally, if you want to get super technical (as if there
| were ever a real delineation between RISC/CISC), both AMD and
| Intel decode x86 into internal micro-ops which are
| essentially RISC.
|
| So, for all intents and purposes, CISC _is_ dead _and_
| buried.
| jcranmer wrote:
| > Additionally, if you want to get super technical (as if
| there were ever a real delineation between RISC/CISC), both
| AMD and Intel decode x86 into internal micro-ops which are
| essentially RISC.
|
| Given that most CISC chips also relied on microcoding and
| micro-ops, x86 having micro-ops wouldn't have made it
| anything like RISC as far as the original CISC/RISC debate
| goes.
|
| The only reason that the "x86 is really RISC because of
| micro-ops" comes up is because x86 implementations are
| superscalar, which was supposed to be impossible with RISC
| chips, so people started coming up with the micro-op fudge
| to salvage the story that you need RISC to be an advanced
| modern microprocessor.
|
| The truth is that CISC was never a meaningful category in
| the first place (it was only ever "not-RISC"), and RISC
| itself ceased to be a meaningful category around 30 years
| ago.
| Kampfschnitzel wrote:
| From what I've seen, most RISC V chips are still far behind x86
| and ARM when it comes to raw power. I don't think the loss in
| performance is justifiable with lower cost (yet)
| choffee wrote:
| I think there has been a big uptake in things you don't see
| like embedded or FPGA cores but as a general CPU it's nowhere
| near as efficient as ARM/x86 right now is my understanding. So
| it might be running in the SSD and the Fan controller but not
| as the CPU. I think a large part of the cost of a CPU core is
| not the instruction set but the optimisation of the CPU and
| ARM/Intel/AMD are still way ahead in those. And so it needs
| people to optimise the cores, which when they have done that
| they charge for being a better CPU.
| rwmj wrote:
| There's a fair bit of adoption where you don't see it (for
| example, if you have an NVidia GPU or a WD hard drive, you
| likely have a few embedded RISC-V cores already). We're
| expecting server hardware with good performance in a year or
| two.
| brucehoult wrote:
| > Always wondered why RISC-V doesn't get more mainstream
| adoption.
|
| It's very simple!
|
| Because the amount of time it takes to design and produce a
| data centre level CPU microarchitecture is greater than the
| time RISC-V extensions needed for data centre CPUs have
| existed.
|
| The original RISC-V specification was ratified less than six
| years ago, but you really couldn't create a data centre CPU
| until at least RVA22, ratified two years ago in March 2023 --
| or preferably RVA23 which was ratified in October 2024 and has
| the features needed for efficient hypervisors.
|
| You can knock out a microcontroller CPU core in a weekend, but
| something to compete with current Apple, AMD, Amazon etc CPUs
| takes a long time to make. Most companies doing that started
| work only in 2021 or 2022.
|
| It is simply too soon. A lot of stuff is in the pipeline.
| OptionX wrote:
| Makes sense. There's always value in a maturity of a system
| especially in the enterprise world.
| junon wrote:
| They're significantly slower than x86 and ARM at the moment.
| usrusr wrote:
| What fraction of the total cost of operating a datacenter do
| you suppose goes into ARM licensing? That's how much more
| efficient than RISC-V an ARM would have to be in order to make
| it the preferred CPU in a "we don't need x86" scenario. That's
| a very low bar to clear (for ARM, not for RISC-V)
| Veserv wrote:
| Any price advantage, even if we assumed a fully mature
| ecosystem with equivalent processors and systems available, is
| massively overstated. ARM had a total revenue of just ~3.7 G$
| in 2024 over ~29 billion chips [1].
|
| In contrast, Qualcomm, just one of many large suppliers of ARM-
| based systems, had a total revenue of ~39 G$ and a operating
| income of ~10 G$. ARM's _entire_ revenue would easily fit into
| Qualcomm 's profit and only increase costs by ~12%. And that is
| just one supplier. You have Samsung, Apple, Broadcom, Google,
| Amazon, Nvidia, TI, NXP, etc. to help round that out.
|
| The total impact of ARM licensing and IP costs is almost
| certainly less than 1%. And given that RISC-V does not
| currently have a fully mature ecosystem, you get to trade that
| for a 1% cost improvement; not really a winning strategy right
| now.
|
| It is likely the main advantage in the long run for RISC-V is
| that not requiring a license might enable a more vibrant
| ecosystem due to removing the licensing barrier which might
| enable better designs at comparable costs (because, again, the
| cost differential should only be on the order of 1% in the long
| run) rather than just creating comparable designs that just
| chip off the licensing cost. That or RISC-V could win because
| the giant manufacturers feel like putting the squeeze on ARM to
| drive 1% off their BoM.
|
| [1] https://www.acquired.fm/episodes/how-arm-became-the-
| worlds-d...
| gary_0 wrote:
| Using 2024 numbers for ARM might not give a clear picture,
| because that was many years after major companies like nVidia
| and WD already switched all their major internal chips to
| RISC-V. ARM's lunch was already partly eaten; many billions
| of RISC-V chips were already in the wild in 2024. And
| companies like Tenstorrent have been building high-
| performance stuff on RISC-V for a while. If Jim Keller thinks
| RISC-V is worth it, the advantage must be worth more than 1%.
| Veserv wrote:
| That speculation is trivially incorrect. ARM had a revenue
| of 3.2 G$ in 2023, 2.7 G$ in 2022, 2 G$ in 2021.
| ValdikSS wrote:
| How's it different from box86/box64? It also has RISC-V with JIT
| support.
|
| https://box86.org/
| sylware wrote:
| Funny, I am doing exactly the other way around: I run small RV64
| linux programs on x86_64 linux.
|
| I cannot way for the first AAA games to run on ultra-performant
| RISC-V(RV23+) microarchitectures made with the state-of-the-art
| silicon process.
| gitroom wrote:
| Love that folks are hacking stuff like this already, even if
| RISC-V still feels ages behind x86 for anything heavy. I def
| wanna see how far these emulators can actually push things. Kinda
| makes me hope for that wacky Steam-on-RISC-V future lol.
| _joel wrote:
| Almost heh
| https://www.reddit.com/r/RISCV/comments/1jfkng6/windows_stea...
___________________________________________________________________
(page generated 2025-05-02 23:02 UTC)