Well, here are the tricks: interpreted rv64 assembly will be "slow"... actually "slower" than x86_64 native code... but in many execution contexts, for many pie

Well, here are the tricks: interpreted rv64 assembly will be "slow"... actually "slower" than x86_64 native code... but in many execution contexts, for many pieces of software, here the first trick: the "slow" interpreted rv64 assembly machine code will be... "fast" enough... The 2nd trick: I have control on my rv64 machine interpreter, and I can write native x86_64 acceleration assembly along side of a rv64 reference implementation (I planned to do just that for my CPU renderer in my wayland compositor... actually I have already AVX2 code for some of that, even though the sweet spot is AVX512, but don't have the hardware for this, yet). And once we have this rv64 shiny hardware, certainly won't be a drop-in, but the distance to code will be minimal. One important SDK thing: I am careful at using the smallest number of rv64 machine instructions (we tend to forget 'R' in "RISC-V" means 'R'educed...), and I use basic, really basic, C preprocessors instead of the assembler preprocessor in order to decouple the assembly code from a specific assembler preprocessor. I don't even use assembler pseudo-instructions, or ABI register names, neither compressed machine instructions. On top of that: I don't use ELF, I use a super minimal executable/system interface dynamic shared library format of my own, omega idiotically simple, which I wrap in ELF binaries for transparent support. People have to come to realize, ELF complexity, for a executable/system interface dynamic shared library is utterly and completely obsolete, even a liability once you are looking for binary stability in time (cf games), proven over more than the last decade.