But they are ignoring the basic lesson of "new" CPU designs from Transputer to i432 to Itanium to Transmeta.

A new CPU design is easy, it is the compiler to use it that is the hard hard part.

Looked at another way, CUDA is a huge reason NVidia is so big right now. Their GPUs are broadly similar to AMD. Their software libraries are better.

But good luck to them, perhaps they have some great new idea. We need one.

We're in a wildly different world from the one Itanium got to live in and compilers are something with a super tight automated verification loop that can make LLMs thrive. Add that plus cheap formal verification and I think this concern goes away almost completely.

This was pre-2026 story. CUDA isn't a moat anymore.

Now it's mostly market dynamics: People always ship ad optimize things for Nvidia because it's the most widely used platform, and people buy it because it has the most software.

This is much less of a barrier than it used to be though. Buggy AMD GPU drivers remain a problem though.

here they can do multiple programs

In all seriousness congratulations on finding $30 million to launder and lose immediately. Hope your Porsche runs good.

Err..

Are Apple Silicon and Nvidia Vera and Amazon Graviton are considered illegitimate or non-competitors for some reason?

Nvidia Vera and Amazon Graviton are both primarily Linux platforms.

Also some GPU instructions are several times more complex than the most complex cisc instruction from the 90s.

To be honest, CISC versus RISC has not been a useful distinction in architecture design for 30 years. Intel managing to make a superscalar CISC processor, the Pentium, should have put to bed any idea that there's a fundamental distinction between CISC and RISC that is useful.

The reality is that RISC isn't a single idea so much as it is a collection of ideas for how to design a microprocessor, and some of those ideas have turned out to be good and some of them have turned out to be bad. Rather than evaluating on the merits of RISC or CISC, we should evaluate on the merits of the embodied ideas. Let's stop trying to view 2020s design decisions based on 1970s models, okay?

It's not like CISC or RISC are architectures like Transformers or Mamba. They're design philosophies with a huge amount of overlap and leeway.

Subject: x86 evolution for segmentation and paging

https://lore.kernel.org/lkml/CAKSQd8WX6xH7=njcGZNNFe8m1xbyhC... https://sourceware.org/pipermail/binutils/2026-September/151...

no-can-do the legacy-at-any-cost cargo cult crowd will say, of course

but... someone did apparently build it at scale already... so... who knows, eh?

Not sure why this one will succeed where its forebears didn't.

https://www.newcomer.co/p/scoop-benchmark-backs-early-stage

VC is such a meme lmao. What’s next, Sam gonna acquire the company? No product needed!

"Instead of starting from a sequential design, we’re building our processor to have thousands of cores operating in parallel. This requires moving beyond the notion of shared mutable memory and linear instruction sequences. To make this possible, we’re working in tandem on the open-source language Vine, which has been designed from the beginning to target a new wave of parallel-first architectures."

I wish them well but from their Vine language docs:

"For example, a < b < c is equivalent to (a < b) & (b < c)"

So how do you parallelize that? You can run the first part on 2 cores in parallel, but there is still a single check, a single cache, a single CPU for this to go through to complete the operation, right?

They just described a common superscalar optimization thats been done since the 90s.

With that context, this page is explaining `and` short circuits and `&` does not. The `a < b < c is equivalent to (a < b) & (b < c)` is just showing how that logically works, not how to utilize it to parallelize that particular comparison.

This exists to allow you to control whether parallel computation should happen or if it should resolve the first condition before wasting parallel compute to resolve the nth condition(s). E.g. imagine something like `isEven(x) & len(factor(x) > 2` vs `isEven(x) and len(factor(x) > 2`.

It depends on the scale of the computation. An Out Of Order CPU can allready exploit some parallelism at the instruction level. Multicore is parallelism at the procedure level.

Sounds like tweaking a gpu so it can be used like a cpu. There are some proof of concepts running unix on a gpu, along with some toy projects like gameboy emulators. I think an Nvidia engineer even tried to see if they could get linux working which helps explore what is deficient. And there is this https://github.com/robertcprice/nCPU .

Pitchbook shows it as "Out of Business" since 2019.

For comparison, RISC-V started years later and had a tapeout within a year and working silicon available as a commercial product in seven years.

2003: Mill computing started

2010: RISC-V project started

2011: RISC-V first tapeout

2017: RISC-V production chips available in the market

2019: Mill computing dead?

The Mill was (is?) a much bigger swing, with much bigger problems to solve in getting to production.

They specifically wanted to avoid the kinds of "quirks" that vendors like Intel and ARM used to make people subject to their patents.

They did try to avoid what they saw as the blunders of past designs, like not leaving enough opcode space for compressed instructions, making instructions conditional, leaving out byte and halfword memory access instructions, having a flags register, having a complicated page table structure, having register windows, having delay slots, etc. None of that was innovative. The actual design of the compressed instruction set and the vector instruction set were innovative, but that came later.

Sure, but even so they should have made real chips and iterated on silicon, not just simulations.

It’s the SpaceX rapid iteration development cycle vs NASA waterfall.

Even in 02016, I don't think US$2M was enough to tape out a silicon prototype of a working high-performance CPU. MPW ("shuttle") programs can give you working prototypes for as low as US$3000, but only in process nodes a decade or more behind the state of the art. US$30M is a much more plausible budget.

Huh? LB(U) / LH(U)

https://www.sigarch.org/distance-based-isa-for-efficient-reg...

The history of general-purpose massively parallel machines isn't good. From the Illiac IV to the Playstation 3, there's been dud after dud in this space. You can build them, but the users don't come. This sort of architecture is great if you have some specific problem that parallelizes, such as finite-element analysis or neural networks.

(I've used an NCube, and I kind of liked the Transputer concept. But both were dead ends.)

Personally, I wasn't impressed by the press release. It is so vague that it makes it look like they don't know the history of their field or they are outright ignoring it to make their product sound novel. The former is just as problematic as the latter. There are reasons why parallelization is typically offloaded onto coprocessors and reasons why the introduction of new CPU architectures are rares.

Failure is all but guaranteed---a chip is nothing without a computer-manufacturing-distributing ecosystem, which implies handsomely beating existing CPU/GPU makers, which is practically impossible.

My feeling:

An "Epic win" outcome for these people would likely be exit to a leading chip maker, about a decade out from today.

Success would probably look like becoming a mini Texas Instruments type, making specialist CPUs for orgs that can build their own computers around said chip.

Failure would likely be a fire sale into some giant IP portfolio (hopefully not a patent troll... that would be tragic).

i.e. A worthwhile endeavour, in any scenario, for those building the thing.

That being said, it is great that people are still attempting to disrupt the hardware space, even if there's dud after dud historically. Got to respect that!

From an armchair commentary perspective, my understanding was that the PlayStation 3's Cell processor had essentially two practical issues:

- It required extra talented software developers to be able to utilize the hardware to its potential.

- Almost all game makers wanted to also target the Xbox and potentially also PC which further discouraged the writing of platform specific code to truly utilize the unique capabilities of the Cell processor.

However, with AI today, it's completely possible that it changes the economics of being able to write software which can fully utilize new and novel architectures affordably.

So perhaps if the a Cell like processor was released today it would be more successful.

The idea of the Cell architecture is that programs were supposed to be organized as an assembly line, with data flowing into a processor in a stream, and coming out the other side after processing. That's a good fit to audio processing.

Each of the seven support processors had only 256KB (not MB) of local RAM, plus a wide long-latency path to the 256MB main memory, the other support processors, and the PowerPC CPU.

That 256KB was the problem. Not enough for a frame. Not enough for a level. Not enough for AAA title games.

That's the problem with the lots of little processors approach. If all the little guys are memory-starved, you can't get much done, except on very regular problems. Finite element analysis and neural nets are the big wins for such architectures. They're not general purpose.

Note that GPUs aren't arrays of isolated CPUs. All units work against the same memory, mostly. They're closer to shared memory multiprocessors.

I'm not complete sold on that one. You will need training material. While there have been impressive results even for architectures/programming languages for which I would not have expected to be much training material to be available, there will be a minimum. I'm afraid for a new architecture unlike everything else, your AI coding assistant won't be of much help.

With AI today, it's completely possible that it can't change the economics of being able to write software which can fully utilize new and novel architectures affordably.

So essentially it's gambling $30M on a coin toss that a clanker can magically fix something that hasn't worked the last 200 times we tried it.

Nvidia bought the architecture and killed it, which kind of proves your point.

The other problem is that automatic parallelism with the right language is actually easy, but the scheduling cost eats the gains because you cannot launch subtasks in the 100s of nanoseconds timescale.

What's needed is hardware accelerated scheduling within the same process so that you are no longer being slowed down by the software scheduler in the kernel.

Single threaded programs being normal was originally from almost no systems having more than one core or CPU. Then there were few languages that had threading built in. Someone knowledgeable would have to use the OS API to launch threads.

After that threading has mostly come from structures that are already built. There is nothing difficult about copying data if that's what people want to do. There is nothing that says scheduling has to be slow since you can have threads taking data from a queue. None of this has anything to do with rust.

you are no longer being slowed down by the software scheduler in the kernel

This isn't necessary if you just create threads and let them grab data they need, work on it and move on.

Same machine, with one broken CPU? Few of those things were made, so it might be.

[1] https://vine.run/

"Instead of starting from a sequential design, we’re building our processor to have thousands of cores operating in parallel. This requires moving beyond the notion of shared mutable memory and linear instruction sequences. To make this possible, we’re working in tandem on the open-source language Vine, which has been designed from the beginning to target a new wave of parallel-first architectures."

Reminds me of the Transputer and Occam. Each transputer had 4 comm links to form a flexible network of processors and Occam supported parallelism. Also one of the first languages to use indentation for block structures.

For a long time I missed their folding editor.

Who's the customer that wants an exotic architecture on an old process node running a custom programming language half a decade from now?

others have made entire OS's or gone back in time reinventing of removal of the OS and just running a single application with its own I/O stack per application

this is a guess that exotic architecture on old nodes means that the hardware can come out now at a lower price - or at least fulfill market needs at the price the market can bare without the delay - all because using exotic architecture is easy now, unstable opaque drivers are no longer an issue, and there is just a need to fulfill compute demands efficiently

this technology to make it easy is only a couple quarters old

the antiquated understanding of “CUDA being sooo stable and AMD drivers not” just takes a while to be revised

hyperscalers are buying AMD GPUs

AMD’s stock has tripled this year based on investment into their driver stack getting better and others realizing they don’t need to wait for AMD to leverage the compute

Doesn’t really matter how easy rewriting something is, it’s still a waste of time if it brings no value.

I loved the mill architecture (self declared clean sheet cpu).

I thought transmeta had a good chance because they could inline across kernel boundaries.

But none of them was special enough.

Other than that, I don't think there's much relation between the two.

I couldn't find any parallel constructs in the language. So, as I understand it, it's a regular language that gets compiled into a graph, and the runtime parallelizes the execution of that graph.

This factorial won't run any faster with more cores, since each step depends on the previous one:

  fn fat(n: N64) -> N64 {
    if n <= 1 {
      1
    } else {
      n * fat(n - 1)
    }
  }

  fn fat(n: N32) -> Nat {
    if n == 0 { 1 as Nat } else { prod(1, n) }
  }

  fn prod(lo: N32, hi: N32) -> Nat {
    if lo == hi {
      lo as Nat
    } else {
      let m = (lo + hi) / 2;
      let left = prod(lo, m);
      let right = prod(m + 1, hi);
      left * right
    }
  }

Also, as the graph grows, sequential dependencies still limit the speedup, and more cores means more data moving between them. How does the hardware deal with that?

[1] https://tendrils.co/blog/2026-04-26/on-inets

Looking forward to seeing how the hardware handles the cost of communication between cores.

I think the on-chip bus interconnect and ALU are probably going to have some finite width, though. Above that number of bits in an operation, your instructions will get slower. Maybe that's what you have in mind, and you just want to abstract that away?

But I'm thinking more about having multiple logical CPUs, ALUs, or ports working on a single giant register. I think SIMD wastes a lot of hardware.

Example: radix sort needs to calculate a prefix sum. As the sum accumulates, it requires more bits, so the bit length should be adjustable. On x86, you can cast an array of bytes to a uint64_t and calculate eight prefix sums with a single multiplication. But eventually, you run into SWAR lane overflow problems. Ask an AI what this means and how the code works.

We need a CPU designed to handle lane overflow and dynamically adapt bit lengths, so at the start we do more parallel sums with less bits, and as the sum accumulate we increase the bit length gradually. This is just a simple use case. We could store more prefix sums as a periodic sum more deltas.

Besides a lower clock frequency, such a CPU would also have a power consumption, due to a greater total capacitance of the internal nodes.

The number of problems whose solution could be accelerated by such a structure is too low to make it worthwhile.

You'd essentially have a 1 bit processor with a cache that translated groups of bits to whatever memory access width was. CPUs already fill cache lines with transfers wider than registers, so the theory is there.

There's always a sweet spot for bang-for-buck on any tunable size like that. I doubt it is at 1-bit unless you can figure out how to do cache coherency with a few million cores.

[1] https://bend-lang.com/

https://bil-lang.org is a more explicit language that imo is needed for coders (or LLMs) to grapple with hammering algorithms onto a CPU array. But AI is a big lever to overcome this historic barrier.

I made Bil as a way to try and break that - built on Go (and LLVM) under BSD. Quite easy to run up a simple scheduler for any new architecture particularly if they are an LLVM target.

There's also XMOS[2] that appears to have morphed quite far from the original concept but is still focused on parallelism.

The challenge for both is that it's really hard to carve out a decent sized space alongside regular CPUs and GPUs. They can't compete with CPUs on single core performance, and so far can't compete with GPUs on concurrency. Both seemed to try to carve out space in embedded / low powered systems. XMOS seems to have somewhat succeeded (at least they're still alive), while Parallella/Adapteva failed.

[1] https://parallella.org/

[2] https://en.wikipedia.org/wiki/XMOS

Cache coherency is hardly a waste too. For general purpose compute you need at least some mechanism to exchange messages between cores so the transistor budget is needed. It wasn't convincingly demonstrated that CC is worse than alternatives.

I accept that modern day CPUs have co-evolved with modern compiler backends to be highly dependent on OoO - but the case of the many small CPU folks is that for a large class of performance hungry algorithms there are ways to distribute the workload efficiently over many parallel CPUs with no shared memory. In this case then there is a trade off of "does each CPU do OoO and take more die area" vs. "does each CPU NOT do OoO and take less die area" with proportionately more total datapath throughput per mm2.

I submit that for this class of problem, zero or very little OoO is the optimum. In the fag packet designs I have done it looks to me that a 2 dispatch integer pipeline with a small I-cache is fully capable of filling a 32-bit FP datapath (double pass if you want f64, four f16 per cycle) and in turn that can saturate a 256-bit SRAM unified on chip main memory bus. And, of course, the shorter the pipe to flush and the less deep the main memory latency then good things happen.

Realistically in most applications you can get far more processing power than you need because of clock speeds, modern architectures, transistor budgets etc.

A disposable vape can have an arm cortex m0 that runs at 24 mhz and a $1 pi pico can have a dual core m0 that can run at 133 mhz to 200 mhz.

If you want raw math you can use SIMD or a GPU model and if you need single core power you need out of order execution to hide the memory latency, because that's the real bottleneck for the last 30 years.

These multiple tiny cpu core models just don't make sense to solve any real problem and they create a lot with their complexity and latency trying to communicate with each other.

There just isn't some bizarre niche that needs more math instructions with less power consumption. People have all they need even without being efficient. If someone needs more they turn to writing actual optimized software.

The only algorithms that do not care about memory latency are the digital processing algorithms and the like (which include things like video/audio compression and decompression), where there is a continuous stream of incoming data, which must be processed.

Otherwise, whenever you have to read a previously unused memory location from an address that is not predictable by the hardware prefetcher, you must pay the latency penalty.

There are only 2 ways to hide the memory latency, by doing something else while you must wait the arrival of data. You can either execute instructions taken from elsewhere from the current thread, which is OoO and which requires a lot of complex hardware to find which instructions may be executed, or you can use either fine-grained multi-threading or simultaneous multi-threading, where either the programmer or the compiler have taken care to prepare a lot of independent concurrent threads, so that the hardware may execute any instructions from a thread that is not the current one, without having to search and analyze the instructions, to find their dependencies at run-time.

Because this is much easier for programmers, OoO is preferred for CPUs. Where the cost per core must be minimized, FGMT or SMT with a very large number of threads is preferred, like in GPUs.

In the parent article it is said that they will not use OoO, but nothing is said about multi-threading. If neither OoO nor FGMT/SMT are used, the result is a special-purpose processor, not a general-purpose processor, i.e. a processor whose use is restricted to DSP-like algorithms, because otherwise its execution units would stay idle almost all the time.

I have browsed briefly through the documentation of the programming language mentioned in the announcement, but it does not appear to have many features relevant for concurrent programming, not even of the level of the Occam language, which was used for Transputers.

The only unusual feature that I see, is a Fork/Drop thing, which works exactly like reference counts, except that instead of passing references to an object, copies to that objects are passed, which is an optimization that may be useful in a concurrent program, but it is something that can be done by a compiler, without being visible in the programming language.

So not general apps, nor pure pipeline DSP tasks that map onto a GPU. But I reckon there’s a lot of ground in between that is open for colonisation.

btw https://bil-lang.org is inspired by Occam style CSP and grafts that into Go … so yes a fast scheduler to overlap at the process level and a way to guide LLM via strict chan and par structure

> Instead of starting from a sequential design, we’re building our processor to have thousands of cores operating in parallel. This requires moving beyond the notion of shared mutable memory and linear instruction sequences.

Hey! Sounds like Thinking Machines, that hot new startup out of MIT. Yeah, their Connection Machine was bleeding edge stuff... in 1983 (https://en.wikipedia.org/wiki/Thinking_Machines_Corporation). Look, I get that it's an overview but they need to at least hand-wave at something new and different before talking like it's new and different.

I guess these are all really expensive and need VC funding. But perhaps there are existing architectures that allow baking code into silicon, or new architectures for NNs and so on. If costs are low, there is a massive demand coming for code that we want to write and forget - keeps on running on low powered last-mile devices. From factories, farms to home equipment.

All the best to anyone trying to design a new paradigm of processor, but I'm interested to hear how they'll avoid the pitfalls of their predecessors.

It’s a reasonable bet that LLMs will make translation to other architectures effectively automatic. So that moat may completely disappear.

I couldn't quite follow the diagrams of the theory page, but I'd be willing to bet a very small sum of cash that it'll eventually be something very much like the BitGrid.

  > Tendrils is answering the question: what if we redo the CPU? Instead of starting from a sequential design, we’re building our processor to have thousands of cores operating in parallel. This requires moving beyond the notion of shared mutable memory and linear instruction sequences. To make this possible, we’re working in tandem on the open-source language Vine, which has been designed from the beginning to target a new wave of parallel-first architectures.

Ten days ago there was a post that linked a Haskell-specialized CPU, please: https://news.ycombinator.com/item?id=50319896

The link to the CPU demo: https://bathtub-01.github.io/technical/ouros-demo/

The Ouros CPU is a dataflow CPU, which means it is very, very scalable. It does not, from what I read there, contain content-addressable memory, which is a bottleneck for dataflow architectures. It supports multithreading from the ground, a parallel Haskell program will be executed very efficiently there.

There was an Id, a dataflow lenient functional programming language. The Id90 version of it was ported to Thinking Machines Connection Machine (then) supercomputer (I believe it was ported to CM-4 and CM-5).

Id90 programs running on Connection Machine demonstrated linear scaling to the available compute and, sometimes, even superlinear scaling - Id90's Content Addressable Memory was implemented in software and when CAM slice become smaller, there were less cache misses. Some of Id90 programs produced so much parallel computations that compiler had to introduce throttling so CAM will not overflow.

Here's a thesis on compilation of lenient functional programming languages to CM-5: https://www2.eecs.berkeley.edu/Pubs/TechRpts/1994/5850.html

I guess it shows that functional programming languages can be efficiently executed through parallel dataflow architectures and that dataflow architectures scale efficiently with compute.

I am putting it all here because I see the same pattern over and over again. People create some new language with some unknown properties (Rust, for example, got Turing-complete type system before being able to control for I/O) instead of first taking Haskell and embed their ideas there or, even, add an extension to play and/or investigate.

In this particular case, they take some Vine programming language instead of Haskell, despite Haskell already having several specialized CPU implementations, including dataflow one, guaranteeing scaling. And Haskell has a pretty mature infrastructure and tons of libraries.

Why? I don't know.

  > Instead of starting from a sequential design, we’re building our processor to have thousands of cores operating in parallel.

It has a better foundational data structure that enables very cheap and fine grained control operation (multithreading, etc).

The first is that they would spend all their time waiting on memory. If you run a CPU at 5 ghz, you will have 500 cycles before you get the bytes from memory you want. 1% of a modern CPU is running the instructions, the other 99% is trying to keep it busy. You would then need to double the transistor count for cache, but even then you will be waiting on memory for everything that you haven't already used and put in cache. To counter act that you need prefetching so you can get from memory ahead of time etc. This goes on and on until you either build a modern CPU or a modern GPU.

The other problem is that this doesn't solve a problem anyone has. People aren't really clamoring for more raw math or instructions any more. Most of it goes to waste by running scripting languages that run at 1/100th the speed of naive C. Most C runs at 1/100th the speed of a real optimized program. It's as if someone built a super powerful engine and everyone just decided to fly jumbo jets to work instead of using the same cars and less gas.

Then finally there are modern GPUs which already can do one million floating point operations in the time it takes to get a single byte from memory (the single byte is really two cache lines which is the minimum and this also includes the memory not being in the TLB).

It's all memory latency and software optimization. The need for raw math is not a general computing problem any more, it has all been relegated to GPUs.

Waiting for those periods only occurs when a modern cpu is fetching memory outside its caches. When its all in cache it runs at basically full speed.

> To counter act that you need prefetching so you can get from memory ahead of time etc. This goes on and on until you either build a modern CPU or a modern GPU.

Thats all true but what im suggesting is if you had MORE a lot MORE humble cpus even if they run at a much less than GHZ, doing a little work the sum of the humble cpus would actually become more than the modern fast cpu.

Think a lot of slow donkeys would still get move more than a ferrari, for less money and less fuel.

> Then finally there are modern GPUs which already can do one million floating point operations in the time it takes to get a single byte from memory (the single byte is really two cache lines which is the minimum and this also includes the memory not being in the TLB).

Thats all true but the cost of that performance is a lot of heat and silicon.

What if that power was given to a million 6510s ?

I said that exactly. Half the cpu will be cache and it only helps once data is in the cache, which it won't be if you are running through big arrays. Big arrays would be necessary to supply a bunch of tiny cores, unless of course you had prefetching and other mechanics.

When its all in cache it runs at basically full speed.

L3 cache will not run at full speed. The latency is much better but you still have 40 cycles. That means that every lda instruction will wait for 40 cycles when in old computers it would take one cycle. That's just for anything already in cache, not the 500 cycles you would stall for something outside of cache. Don't forget that there are no cache lines and no out of order execution so you pull down a single byte after 500 cycles and if you read the next byte you wait 500 more cycles.

Thats all true but what im suggesting is if you had MORE a lot MORE humble cpus even if they run at a much less than GHZ

Your idea is clear, it's not a misunderstanding, it's just something that has been considered a long time ago and dismissed.

Think a lot of slow donkeys would still get move more than a ferrari, for less money and less fuel.

People don't want slow donkeys, they want to move themselves with a ferrari or jet, or huge amounts of stuff on a giant ship. Donkeys are obsolete. They don't cross water, they don't move fast, they don't go straight.

Thats all true but the cost of that performance is a lot of heat and silicon.

So what?

What if that power was given to a million 6510s ?

You would have the same number of transistors and you would be able to do 0 floating point calculations because those CPUs had no floating point units. You can't even multiply integers. You can add and subtract integers. Now you have to sit and wait on every memory load, you have lower Ghz and every math operation is going to use lots and lots of cycles because you can't even multiply integers. Good luck with that.

The 6510 did not have any cache. Im suggesting the cost/benefit of cpus that do not have any cache, no branch prediction, no out of order, just the minimum to execute its ISA.

Again cutting things down to as simple as possible and hope for the best.

> Your idea is clear, it's not a misunderstanding, it's just something that has been considered a long time ago and dismissed

It was dismissed because x86 has a very large impossibly expensive range of software that would be lost on any new different arch.

> You would have the same number of transistors and you would be able to do 0 floating point calculations because those CPUs had no floating point units.

The 6510 could do floating point in software. Im not saying that the solution must be a million 6510, one could add a simple FPU and advance some of the features. Im just suggesting an arch without all the extras that require lots of transistors like Out of order execution, caches and all that.

Right, again this is clear. Although you did talk about cache earlier, it's not a mystery what you are trying to say. It's simple, easy and doesn't work.

Again cutting things down to as simple as possible and hope for the best.

These old CPUs are extremely efficient with transistor budgets but they do almost nothing.

It was dismissed because x86 has a very large impossibly expensive range of software that would be lost on any new different arch.

This is completely wrong. If this architecture worked, there would be a 100,000 original x86 cores on a chip. You can look at the evolution of x86, super scalar computers like cray machines, the successors to the 6502, chips from sun, dec, SGI etc. and see what they added and why.

There are new CPUs running riscv that you can buy right now and they don't do anything like this even though it is running on a completely new instruction set.

The 6510 could do floating point in software.

32 or 64 bit floating point numbers using just 8 bit integer add and subtract with bit shifts. Kind of seems like the thing that would be much better done in hardware. Maybe do 8 or 16 floating point operations in a single cycle.

one could add a simple FPU

The first FPU was 45,000 transistors. Now each chip isn't 3,500 transistors any more. Don't forget you are still moving single bytes around with every instruction, many instructions take more than one cycle to complete, you have almost no registers and the ones you have are all 8 bit and because you have no cache, every memory load takes hundreds of cycles while the cpu sits and does nothing.

Im just suggesting an arch without all the extras that require lots of transistors like Out of order execution, caches and all that.

Again, it's obvious that you are suggesting that and with a little research it's obvious why it doesn't work out.

2006: Sony & Toshiba & IBM (STI) - Cell Broadband Engine

2009: GreenArrays - GA144

2012: Adapteva - Parallella

2021: Esperanto Technologies - ET-SoC-1

2024: Inspiresemi - Thunderbird

Sounds like this is trying to go an order of magnitude further past that, but I'm not particularly optimistic it'll amount to much.

https://en.wikipedia.org/wiki/Interaction_nets

http://rexcomputing.com/

https://news.ycombinator.com/item?id=40514424

https://microarch.club/episodes/10/