Even if there are not that expensive to implement, I do not use official ABI register names, neither pseudo-instructions (I use a command to generate the code on the side).
Once RISC-V has performant silicon implementations (server/desktop/mobile/embedded), the really hard part will be to move the software stack, mostly closed source applications like video games.
And a very big warning: do NOT abuse an assembler macro-preprocessor or you will lock your code on that very assembler. On my side I have been using a simple C pre-processor to keep the door open for any other assembler, at minimal technical cost.
The games are barely moving to ARM, they won’t move to yet another architecture. Desktop games will remain x86 windows for the foreseeable future merely due to the existing catalogue.
The only exception is console games, where the architecture doesn’t matter anyway.
Yep, the super hard part: this rv64 "catalog" is empty.
If you put emulation (hardware accelerated or not), game devs won't compile for rv64. Look at how valve proton is hurting native elf/linux gaming: game devs hardly build anymore for native elf/linux (but this may be related to the toxic behavior of some glibc and gcc devs though), even though their game engine has everything linux support.
It's also how easy the userland can break things. Windows backwards compatibility tends (even if it's not 100% successful on this) to stay relatively stable. It's kind of funny that the most compatible way to distribute Linux binaries for games is to target Proton/Wine.
proton/wine has no official technical support hence illegal in tons of countries.
Since proton/wine is unreliable in time, this is a disaster.
And there is a lot of BS around that: if some devs support their game on elf/linux via proton, they will have to QA it on a linux system anyway, so it does not change that much, even less with a game engine which has everything linux already... it only add the ultra-heavy-complex and then bug inducing proton/wine layer... an horrible mess to debug. One unfortunate patch, proton/wine side or game side, and compat is gone, and you are toast... and those patches do happen.
Conclusion: the only sane way is PROTON = 0 BUCKS.
I play only F2P games with proton (mostly gachas), no way I'll pay bucks for a game without technical support.
Valve should allow to pay games _only_ for the games with official elf/linux/proton support (aka the game devs do QA on elf/linux with valve proton... which would be no better than stupid if their game engine has elf/linux support already in). Why not let elf/linux users play all games which do not have official elf/linux support for free, well, those which run, and run decently, and until an unfortunate patch...
Once RISC-V has performant silicon implementations (server/desktop/mobile/embedded), the really hard part will be to move the software stack, mostly closed source applications like video games.
And a very big warning: do NOT abuse an assembler macro-preprocessor or you will lock your code on that very assembler. On my side I have been using a simple C pre-processor to keep the door open for any other assembler, at minimal technical cost.