The sunk cost here I think refers to the existing CPU designs of the respective camps. Qualcomm's ARM-based cores don't support an equivalent of the C extension and adding it would presumably require major and expensive rework.

>> This is basically what qualcomm proposes, 32 bit instructions and 64 bit aligned 64 bit instructions.

Well that's only sunk cost if they assumed from the start that they were going to change the design to RISC-V AND drop the C extension. In that case, it was a rather risky plan from the start - assuming they can shift the industry like that. I'm guessing RISC-V was a change of direction for them and this would make things easier short term.

Debian has already started compiling it, and even more will be by the time this new incompatible ISA would hit the shelves.

The time to 'get it right' has already passed IMO. If a hard ISA compatibility break happens at this stage, who is going to trust that it won't happen again?

Can’t Debian just recompile it? I think that was OPs point. We’re not at a place yet where _only_ binaries are floating around we have all the source code for these applications.

Reading through this thread, I think that if the conclusion is to disallow misaligned 16-bit instructions, then not much has to happen.You technically only need to relink the programs to fix that issue.

The question is really about how far do they want to go beyond just disallowing page-crossing / cacheline-crossing instructions.

Personally, I always thought the C extension would have been much easier to implement if it had certain rules about it. Imagine looking at a random location in memory, how can you tell where instructions begin and end? You can't.