[sylware]

For my personal case, I found out that writing "real programs" in anything else than assembly with a conservative usage of a macro processor is kind of toxic: it is a complex matter based on my experience and what I could understand from "software history".

A high level script language would be such "real program". Idem for a command shell.

risc-v, if successfull, will help a lot to this then remove a lot of what I consider toxic.

[Jtsummers]

Are you actually saying all programs should be written in a macro assembly language? Tied to only one hardware platform, with high level concepts completely obfuscated by the need to express them in assembly? So when MS wants to make an ARM version of Windows, rewrite! When Apple switched from 68k to Power to x86/x64 to ARM, rewrite! Port the Linux kernel to a new platform, rewrite! Port the unix utilities to a new platform, rewrite! Any application writer wanting to port their program from one hardware system to another, rewrite!

That would be an awful world to live in, though more people would be employed. Less would actually get done, though.

[sylware]

That's why I cited risc-v. Standard of interoperabitily at the assembly level.

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

[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.

[cnt-dracula]

Why do you think so? I assume that writing the same piece of code in assembly would take more than twice as long (conservative estimate) if you do the same in high level languages without much benefit. Can you elaborate your opinion a bit more as I am curious. I have been wanting to get into learning assembly but just cant seem to do it as high level languages are so easy to code in and want to know if anyone really uses assembly nowadays.

[sylware]

You are perfectly right. Basically, it is "moving the lines".

Taking more time to code, even duplicate some code paths for major ISAs is saner than to depend on the planned obsolescence of grotesquely and absurdely massive compilers and many computer language syntaxes. See that as short term thinking vs long term thinking.

You would find some kind of middle ground when combining those with high level scripting languages.

Think about a world where many code paths are available in risc-v assembly, with risc-v written python-like interpreters.