Unless your software is written in assembly you can probably reuse a lot of that when moving to a new architecture. And given that interpreted/JITed languages are pretty mainstream these days I'm sure many developers wouldn't even notice the difference if you swapped their CPUs during the night.

Does that matter for some cases.?

Linux supports arm and we have massive companies where economies of scale and a Linux/OSS plus their code could all be cross compiled, I mean if your the average biggish none tech company then yeah you might be stuck on x86 because of windows but that isn't everyone.

In any organization if you have an internal tool or software it’s not like you can press a button and make sure it is cross compiled to ARM from x86. That is a huge and expensive undertaking.

>> In any organization if you have an internal tool or software it’s not like you can press a button and make sure it is cross compiled to ARM from x86. That is a huge and expensive undertaking.

That depends on the software. Many linux distributions can be compiled for x86, ARM, PPC, RISC-V, and even some others. Cross compiling is not difficult if your software is written with even a little of that in mind. Windows itself used to be available for 3 or 4 instruction sets - and an OS requires low level hardware support. Applications should be largely target independent.

Lots of x86 code plays fast and loose with alignment which will blow up on ARM.

Modern big ARMs let you play fast and loose with alignment as well.

Hell, a CortexM3 lets you have unaligned loads and stores too.

Even if they don't you can just turn unaligned access emulation on in your OS kernel. This was a thing in QNX and is also a thing in Linux.

I think it's fair to not want to turn that on in the kernel on chips that don't support it in servers. It's really expensive on those kinds of cores to trap into the kernel (a KPTI makes it dramatically more expensive).

That being said, server cores with their long me or pipelines are the most likely to not have an issue with unaligned access, so it's probably a moot point.

That software is either poorly written, or has low level stuff that needs to be arch specific or rewritten. Most code does not have this sort of issue.

Most startup workload is internally built software that we only need the compiler and/or runtime to be optimized for the architecture.

Most enterprise tools are written in higher level languages like Java, Python, C# and many other mostly platform independent technologies.