[Jtsummers]

> Yes, and porting from 1 assembly to another is easy.

So I disagree with this because it discounts the actual differences between hardware systems (including RISC-V variations, 32-bit memory addresses versus 64-bit, different sets of instructions depending on the underlying variant). Then again, I've worked with systems that gave you complex number registers which are not terribly common on any other system. Could be translated away (and sometimes was, but usually to a high level language first) but if you stuck to assembly you exploded the instruction count to do so since now you needed complex math routines (among other things) that were baked into the older system.

But let's say it is easy, then you are either wasting a massive amount of time doing something by hand a computer can do for you (only a fool does this for long), or you have a computer do it for you. At which point your ISA I Assembly->ISA II Assembly translator becomes, wait for it, a compiler. And then you have a really shitty language (some old system's ISA) instead of an actually useful high level language.

EDIT: And suppose, somehow, you kill all non-RISC-V ISAs (good luck). How do you handle other hardware like GPUs? Do you really expect a common ISA to form there any time soon?

[sylware]

As I said, I do agree to "pay this price", because I am literally fed up to pay the other price of dependency on very few grotesquely and absurdely massive compilers and the never ending planned obsolescence of computer language syntax.

And high level script interpreters (python-like/swift-like/lua-like/javascript-like/etc-like) written themselve in assembly would be around.

In the interim, I would still code plain and simple C (probably "stuck" at c89 with benign bits of c99/c11), but using the most idiotic small and simple compilers out there, and never ever use gcc or clang to compile it.

And with risc-v, even ultra-small risc-v SOCs offer at least a 64bits core, so I would stick to 64bits.