Linus Torvalds (torvalds.delete@this.linux-foundation.org) on May 24, 2022 12:11 pm wrote:
> ⚛ (0xe2.0x9a.0x9b.delete@this.gmail.com) on May 24, 2022 11:49 am wrote:
> >
> > "The kernel side is fairly trivial" - that is completely absurd. Please read
> > https://www.realworldtech.com/forum/?threadid=206023&curpostid=206307.
>
> I did. There's absolutely nothing interesting in it.

I don't understand why you are using superlatives so much in text. It is detrimental. "absolutely nothing" - is that like zero Kelvin (−273.15 °C) or something like that?

> Your argument about two-way communication is just ranting.

I also wrote that I do not know (am unable to predict) which method will prevail over time.

> The fact is, you want solid and stable ABIs for kernels, and you don't want some malleable and complex interface.

In my opinion, you are mistaken in this instance. The C programming language is what it is: just a higher-level form of an assembly language. I suppose we need to wait a couple of decades for more advanced programming languages for kernel&application development to emerge, and then the problems which are to a great extent attributable to the relatively primitive nature of C will disappear. (For clarification: by a more advanced language than C, I do _not_ mean Go/Java/Rust/etc.)

The point is: The reliability of the kernel--userspace interface partially depends on the expressivity of the programming languages being used. Data and objects that are impossible to check/verify by a compiler cannot, by definition, be part of a solid interface.

> > I suspect that your negative personal experience with Transmeta has "inoculated/vaccinated" you for
> > life against most kinds of just-in-time compilation, binary translation and related technologies.
>
> We have a runtime JIT with binary translation in the kernel already. It's
> called ebpf, and it's in quite active use for its intended purpose.
>
> And it has absolutely no bearing on this thing, or on other parts of the kernel.

I know that ebpf exists. I don't understand what kind of argument you are trying to make here in relation to hetero-ISA CPUs.

> Anybody who thinks that binary translation is a replacement for static code generation is just living
> in their own dream world.
> It's just a tool in a toolbox of things, and has its own serious problems.

"binary translation being a replacement for static code generation" - I suppose I never wrote, nor implied, such a statement. Binary translation is (in simplified terms) from static-form-1 to static-form-2. Maybe you meant "JIT being a replacement for static code generation"?

----

It seems to me that some (most?) of your claims here are based on the [invalid] assumption that homo-ISA multi-core CPUs don't have their own serious problems compared to hetero-ISA multi-core CPUs.

Let me write it using your terminology: anybody who believes that 128-core homo-ISA desktop/notebook CPUs are the future is totally crazy.

The reason for that is that a 128-core homo-ISA CPU would run software slower than a 32-core hetero-ISA CPU. The fact that 256-core homo-ISA CPUs will be useful on servers does _not_ imply that such CPUs will be the best choice for notebooks and desktop machines.

-atom