rewrite it from scratch
For most programs all is needed is just a recompilation.
And with FOSS there is also no need to ask the developer. Debian Linux already has more RISC-V software than Windows has ARM.
Comment on Qualcomm's Powerful PC Chip Is Worse for AMD Than for Intel
FunkPhenomenon@lemmy.zip 8 months ago
stop trying to make x86 software work on non-x86 architecture. dont port the code, rewrite it from scratch to support the arm hardware.
rewrite it from scratch
For most programs all is needed is just a recompilation.
And with FOSS there is also no need to ask the developer. Debian Linux already has more RISC-V software than Windows has ARM.
I recently bought an Apple Silicon laptop and I’ve noticed that only a handful of my apps are run in Intel translation mode. Intel apps are significantly slower to launch because they front load the code translation, but I’ve been surprised to see how much software is fully native or universal now. Apple has done a good job giving developers the tools to write code that is portable, but it’s been stretching the pain over servers revision cycles. For example dropping 32bit software support two versions ago. I am not convinced Microsoft has the nerve to break compatibility but Linux will be fine.
MS is doing it. They are killing Outlook and moving to New Outlook. I can’t think of any other app that is as important as that one.
I don’t mean Microsoft apps. I know those will work fine. I mean all the effort Microsoft has put into making sure that Windows remains compatible with very old third-party software, including drivers.
I suspect them moving/re-coding their enterprise apps over to PWA has a lot to do with getting those apps to run well on different architectures.
barsoap@lemm.ee 8 months ago
Software tends to be written against an operating system or slightly more high-level API, not against an instruction set. We’re not in the 1960s, any more, compilers exist.
Even back during the x86 to x86_64 switchover people didn’t re-write software, we mostly just cleaned up legacy code, removing old architecture-dependent tricks that wouldn’t work in 64 bit mode and hadn’t been necessary to achieve proper performance for a couple of hardware generations, anyway.
There’s always going to be exceptions but if your calculator app needs more work than a recompile you did something wrong. Possible sources of nastiness in otherwise well-written software include anything that relies on manual memory layout, mostly alignment issues (endianness isn’t an issue x86 vs. ARM) and very occasionally some inline assembly for the simple reason that inline assembly has become exceedingly rare. I say “well-written” because there’s e.g. C code out there hitting so much undefined behaviour that it compiles on exactly one compiler and runs on one architecture but even then it’s a case-by-case call on whether to rewrite or clean it up. I’d tend towards rewrite in Rust but there’s conceivable exceptions. Also you should’ve fixed that shit up years ago.