@AmenZwa @david_chisnall David, re:

> A processor designed purely for speed, not for a compromise between speed and C support [...]

How feasible do you think it would be to support existing C programs on a system like that through some set of bridging extensions to the C language (maybe something reminiscent of the extensions that were added to ObjC in order to support Swift)?

Does the answer to that question change if we assume that this new architecture supports CHERI or similar?

@JamesWidman @david_chisnall

James, I am aware that your question was addressed to David, and I'm just a little DSP-on-MCU guy who has never designed a CPU microarchitecture.

But I offer my own confined perspective. It is eminently possible to break the x86-C-Linux stranglehold of modern computing. Indeed, well into the early 1980s, that was how things were done. Each new architecture was incompatible with the one prior. Innovation was explosive, and the laws of Moore and Dennard were extent. Such exploratory divergence was inevitable. But once the industry stumbled upon the cost-performance-familiarity tripod in the shape of x86-C-UNIXen, it took the most steady-profit path.

I doubt, though, that today's profit-driven, risk-averse industry has the moxie to take on risky, groundbreaking innovations. No one dares to play chicken with a half-billion-dollar investment that would likely flop—no one would switch from their familiar environment.

Here is a wild thought. Everyone is obsessed with LLMs these days, using them indiscriminately to generate code they cannot understand. Why not just have AI generate Verilog or VHDL and make FPGAs for small-scale and ASICs for large-scale directly, and be done with architectures, languages, and operating systems? (Forgive me; at my age, I am prone to suffer from these frequent pangs of resentment.)

@AmenZwa @JamesWidman

Indeed, well into the early 1980s, that was how things were done. Each new architecture was incompatible with the one prior.

Even by the '80s, backwards binary compatibility was important. The original IBM PC was from the late '70s, the original Mac the early '80s and subsequent iterations of both ran older binaries. By the '90s, most software wasn't written in assembly, but abstract-machine portability was important. Even in the microcontroller space today, you'd be hard pressed to sell a chip that can't run C code: recompiling is normal, but rewriting is not.

But the sunk cost keeps going up. Every year, there's more C code in the world and so the cost of building a completely new alternative ecosystem is higher.

@david_chisnall @AmenZwa @JamesWidman

Taking a step back: do we need this kind of compatibility today? Unlike the 80s when we had that explosion of different holistic but incompatible systems, today we have widely adopted open standards for data and communications formats. This is an advantage that implementers simply didn't have back then. It grants the possibility of making a totally new kind of computing system from the ground up

@darth_cheney
I don't mean to cut in front of others with a quick reply, but this is my week of, so I'm idle, now. And here goes.

Compatibility is essential in all interconnected system. All engineers live by that ethos. In EE, for instance, we have numerous standards, ranging from federal statutes and state regulations down to IEEE guidelines and company policies. But one thing I noticed through the decades is that none of those "commandments" interfere with an individual practitioner's ability to apply mathematical reasoning, engineering principles, and innate creativity to his problem analysis, solution synthesis, and production manufacturing tasks.

The software community (of which I am a member, too), for the past six decades at least, has been desperately trying to convert itself into an engineering discipline, without success. There have been tonnes of software "standards". But none are legally binding and only a few, and narrow, areas (like life-critical applications) of software practice actually follow their own standards.

The baseline in engineering (like in medicine and law) is licensure and continuing education, with serious legal consequences for breach of professional ethics. There is no equivalent regulatory oversight in software—because it is impracticable to hold software practitioners legally responsible. And it is impossible legally to define a court-provable the causation chain of a "bug" as having been caused by accident, negligence, recklessness, or intentional. Even if such a scheme could be developed, there is no reliable way to apportion blame amongst the culprits.

Software is not an engineering practice; it is more akin to an art form.

@david_chisnall @JamesWidman

@AmenZwa

I meant "compatibility" more in terms of the "abstract machine portability" David was describing above.

A totally new computing system can get a long way by speaking standards like TCP/IP and being able to parse common formats like XML, etc, etc., _without_ having to be a unix at all, or having anything to do with C.

@david_chisnall @JamesWidman