This is a "build it and they will come" project.
It's not a "we put the inner loop of ML entirely in hardware" project. That would make more sense technically. You could cram a lot of little independent neural net inference units on one chip. But if it was pitched that way, the questions would be "Why isn't NVidia doing this", and "After you do it, what keeps NVidia from doing it". There are lots of people pitching "AI chips", with modest success.
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.)
Alt: What if it's a "let's build a kickass thing because we wanna, and see how far we can take it" project?
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: It is a worthwhile endeavour, in any scenario, for those building the thing.
- Boom: An "Epic win" outcome for these people would likely be exit to a leading chip maker, about a decade out from today.
- Base: 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.
- Bust: Failure would likely be a fire sale into some giant IP portfolio (hopefully not a patent troll... that would be tragic).
Yes, plus what there are proposing is more like a GPU in a CPU jacket?
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!
I don't think they were saying it was a bad idea, though they may have been suggesting it is a bad investment.
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.
By my reckoning you can build about 256 small fast CPUs each with 16kiB RAM and IO on an M4 die area. Most of a modern CPUs gates are wasted on out of order execution and cache coherency.
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.
Maybe what was missing as the llms to be honest to get these kind of architectures to work as you can have it run optimisations loop against hardware like this.
yeah well there's a perennial problem of needing innovative languages to get this to work (Vine?) vs. the temptation to package this sw with chips and become a closed technology
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.
As a programmer, I always wanted a cpu which instead of having n 64 bit registers, had a single register with 2^m bits, which could be split in arbitrary length sub registers, not all the same size, and could be treated as an array of bits, or a swar machine
That's a fun idea! RV32E is 512 bits of general-purpose registers, RV32I is 1024, and RV64I is 2048. AVX-512's ZMM registers total 16384 bits. So you could have, say, a 4096-bit register which you could access as any of 13 different sizes, from 1 bit up to 4096.
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?
An use of SIMD in x86 is fast ram copy/filling by sending all Avx register to ram with one instruction.
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.
This feels a decade late. I don't really see the value prop for customers in 2026 (or realistically, 2030+). Let's say I'm willing to rewrite all my software to a language that compiles down into interaction nets. Why don't I use HVM2 instead and buy GPUs from Nvidia? If I just want to use an exotic architecture, AMD is shipping dataflow processors at scale today, and they'll license related IP. And if I just want a massively parallel architecture to run my existing ML code on, I could just rent google cloud TPUs instead.
Who's the customer that wants an exotic architecture on an old process node running a custom programming language half a decade from now?
because rewriting your software is easy now, there are plenty of examples of Language Models looking at the architecture in front of them and recompiling themselves, their inference engine and harnes for faster inference on it or whatever their need may be
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
Language models are efficient because they are trained with millions of examples that don't exist for newer architectures, and they are still mediocre to bad on stuff where they hadn't been trained
If software stacks and compatibility didn't matter, AMD GPUs would be in nearly the same demand as Nvidia's. But we know they aren't and that's despite the fact that porting between GPUs is much easier than what we're talking about here.
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 fix their driver stack in order to leverage the compute
New CPU architectures have lived and died by supporting existing software, with Rosetta on Apple Silicon being an example of it working and Itanium an example of it falling apart.
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.
I'm guessing it will be easier with all of these automated (LLM) porting efforts. Also, there can be a middle-ish ground like GPUs where only portions of the program are written in CUDA and exposed via some higher-level API.
They spent way too long procrastinating, with zero silicon after decades of work.
For comparison, RISC-V started years later and had a tapeout within a year and working silicon available as a commercial product in less than 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
RISC-V intentionally contained almost no innovation of any kind. The whole point was to have the most boring, standard RISC design imaginable, without anything clever in it. That's what you want for introducing students to their first RISC architecture, and also as a basis for doing computer architecture or CPU fabrication research: on zero-overhead loops, compressed instruction sets, scalable vector instruction sets, IoT machine learning, indium gallium zinc oxide thin-film transistors printed on kapton, zero-knowledge virtual machines, or whatever.
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.
Yeah, but RISC-V came out of RISC-1,2,3,4; it didn't magically appear our of nowhere. "RISC-V was developed in 2010 at the University of California, Berkeley as the fifth generation of RISC processors created at the university since 1981".
This is above my pay grade but since LLMs have become the 24/7 code writers, I started to wonder if our processing architecture could see much more innovation. I see light-enabled processing, analog processing and other headlines on posts/YouTube. Most are focused on inference though. But there is also the need to run generated code on cheaper, efficient chips.
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.
I always wonder where will x86 be in 10 or 20 years time. As data paths widen for SIMD, how many can they possibly cram , such as more generations of wider and wider groups of instruction with different opcodes and characteristics.
Do you remember the 1990s everlasting arguments about RISC vs CISC? There were so many arguments (online and magazines) saying that "soon" RISC would eat CISC. And yet, it never happened. I'll be dead before the demise of x86. More likely: The computing landscape will get more complex. Probably ARM will become a legitimate competitor to x86 outside of handheld computing, and RISC V will become a legitimate competitor to ARM for single board and handheld computing.
I think you are confusing CISC with specialized instructions. We just ask 3 questions to decide if something is CISC or RISC. 1. Are the instructions 32 bit wide? 2. Can the instruction only operate on registers? 3. Does it use microcoded, multi-cycle state machines for basic instructions?
That's not the usual way to discuss CISC or RISC (and ARM fails two of the three questions anyways).
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?
You are right! I didn't think about about Mac desktops. I was thinking that ARM is a second class citizen for Linux and Win32. X86 is still king there, but that will slowly change.
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)
}
}
This other version can run in parallel, but only because the algorithm was deliberately written that way:
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
}
}
So the programmer still has to think about parallelism; the language just removes the need for threads and locks.
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?
Bom dia, it's my understanding that there is no runtime. The hardware does all of the graph rewrites. If you look at their 'On Interaction Nets' post [1], it seems that part of the pitch is that many programs can be written 'naturally' and still parallelize well.
"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?
Tl;dr: Vine offers explicit versions of short circuiting and non-short circuiting conditions, but non-short circuiting is the default. The above explains that because it uses the `&` operator rather than the `and` operator.
Broken down further: Short circuiting means you can defer computing everything needed to know `c` until you have confirmed you need to know c to answer the comparison chain. If a < b then you might save a ton of work by not needing to ever calculate everything leading up to c. If a >= b then you've now held off even starting to find out what c was until you need to know what c is.
If you have a ton of parallel compute then it's not as big a deal to always compute all 3 in parallel at the same time, even if sometimes a lot of that compute was not needed to answer the question. The upside is you always finish in the shortest amount of time possible, even if c is a ton of work to figure out.
> CUDA is a huge reason NVidia is so big right now. Their GPUs are broadly similar to AMD. Their software libraries are better.
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.
> it is the compiler to use it that is the hard hard part
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.
I think RISC-V is intended to be a simpler-to-implement processor that can also be used as a compilation target for existing languages, b/c it still shares many properties of x86/ARM (e.g. pointers, memory addresses, etc.). I don't think Tendrils' chips are intended necessarily to be able to run existing code, but instead will require Vine to be able to program for their chips.
Other than that, I don't think there's much relation between the two.
Have you seen the new CPU architecture? It's on Mill. It's literally on Transputer. It's on Rock with Sun. It's literally on AMULET. You can probably find it on Itanium. Dude it's on Tesla. It's a CDC STAR original. It's on E1. You can program it on E1. You can go to E1 and program it. Get onto E1 right now. Go to E1. Dive into E1. You can E1 it. It's on E1. E1 has it for you. E1 has it for you.
In all seriousness congratulations on finding $30 million to launder and lose immediately. Hope your Porsche runs good.
Really would like to understand how the mill got going and how anyone can see it progressing at this point. I know folks are working on it on the side but it's just bleh now.
The chip might be great but they really need to rework their overview blurb. I'm no CPU designer but even I know every single thing they mention like it's bold, new 'think different' stuff, hasn't been a 'new idea' since at least the 1990s. For example:
> 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.
> Sources say that the company is already discussing a fast follow-up raise that would potentially value the firm at more than $1 billion. Neither round has previously been reported. Benchmark declined to comment.
I'm quite interested to see how this evolves. But part of me is still being sad, because hardware is rarely the bottleneck these days - as opposed to software.
"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.
This is a "build it and they will come" project. It's not a "we put the inner loop of ML entirely in hardware" project. That would make more sense technically. You could cram a lot of little independent neural net inference units on one chip. But if it was pitched that way, the questions would be "Why isn't NVidia doing this", and "After you do it, what keeps NVidia from doing it". There are lots of people pitching "AI chips", with modest success.
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.)
Alt: What if it's a "let's build a kickass thing because we wanna, and see how far we can take it" project?
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: It is a worthwhile endeavour, in any scenario, for those building the thing.
- Boom: An "Epic win" outcome for these people would likely be exit to a leading chip maker, about a decade out from today.
- Base: 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.
- Bust: Failure would likely be a fire sale into some giant IP portfolio (hopefully not a patent troll... that would be tragic).
Yes, plus what there are proposing is more like a GPU in a CPU jacket?
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!
Being a dead end doesn't mean the idea was bad, things both fail and succeed for complex reasons. This is a tired trope.
I don't think they were saying it was a bad idea, though they may have been suggesting it is a bad investment.
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.
By my reckoning you can build about 256 small fast CPUs each with 16kiB RAM and IO on an M4 die area. Most of a modern CPUs gates are wasted on out of order execution and cache coherency.
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.
Lots of small computers in a grid sounds like GreenArrays by Chuck Moore. His language of choice is FORTH, or more recently arrayForth.
so reinventing the transputer?
unfinished business
Maybe what was missing as the llms to be honest to get these kind of architectures to work as you can have it run optimisations loop against hardware like this.
yeah well there's a perennial problem of needing innovative languages to get this to work (Vine?) vs. the temptation to package this sw with chips and become a closed technology
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.
As a programmer, I always wanted a cpu which instead of having n 64 bit registers, had a single register with 2^m bits, which could be split in arbitrary length sub registers, not all the same size, and could be treated as an array of bits, or a swar machine
That's a fun idea! RV32E is 512 bits of general-purpose registers, RV32I is 1024, and RV64I is 2048. AVX-512's ZMM registers total 16384 bits. So you could have, say, a 4096-bit register which you could access as any of 13 different sizes, from 1 bit up to 4096.
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?
An use of SIMD in x86 is fast ram copy/filling by sending all Avx register to ram with one instruction.
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.
This seems to be very close to RVV in terms of expressive power. The operations are going to be map,fold,filter
Don't forget scan! You know. Prefix sum.
How to make a chip designer's life a living hell 101.
You want RAM?
This feels a decade late. I don't really see the value prop for customers in 2026 (or realistically, 2030+). Let's say I'm willing to rewrite all my software to a language that compiles down into interaction nets. Why don't I use HVM2 instead and buy GPUs from Nvidia? If I just want to use an exotic architecture, AMD is shipping dataflow processors at scale today, and they'll license related IP. And if I just want a massively parallel architecture to run my existing ML code on, I could just rent google cloud TPUs instead.
Who's the customer that wants an exotic architecture on an old process node running a custom programming language half a decade from now?
What dataflow processors is AMD shipping?
The XDNA NPU is a small dataflow processor. Originally derived from xilinx IP.
because rewriting your software is easy now, there are plenty of examples of Language Models looking at the architecture in front of them and recompiling themselves, their inference engine and harnes for faster inference on it or whatever their need may be
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
Language models are efficient because they are trained with millions of examples that don't exist for newer architectures, and they are still mediocre to bad on stuff where they hadn't been trained
They are also good at TDD loops. With good enough testing harnesses and simulators, they can get things done quickly.
If software stacks and compatibility didn't matter, AMD GPUs would be in nearly the same demand as Nvidia's. But we know they aren't and that's despite the fact that porting between GPUs is much easier than what we're talking about here.
its honestly just network effects at this point
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 fix their driver stack in order to leverage the compute
No that proves the point. It took the invention of LLMs and agentic software development for AMD to fix their drivers.
I thought greenarrays was incredibly cool. (144 native-forth cores on a chip)
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.
New CPU architectures have lived and died by supporting existing software, with Rosetta on Apple Silicon being an example of it working and Itanium an example of it falling apart.
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.
I'm guessing it will be easier with all of these automated (LLM) porting efforts. Also, there can be a middle-ish ground like GPUs where only portions of the program are written in CUDA and exposed via some higher-level API.
Hmm. The story over at https://millcomputing.com/ always looked compelling.
Pitchbook shows it as "Out of Business" since 2019.
They spent way too long procrastinating, with zero silicon after decades of work.
For comparison, RISC-V started years later and had a tapeout within a year and working silicon available as a commercial product in less than 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?
RISC-V intentionally contained almost no innovation of any kind. The whole point was to have the most boring, standard RISC design imaginable, without anything clever in it. That's what you want for introducing students to their first RISC architecture, and also as a basis for doing computer architecture or CPU fabrication research: on zero-overhead loops, compressed instruction sets, scalable vector instruction sets, IoT machine learning, indium gallium zinc oxide thin-film transistors printed on kapton, zero-knowledge virtual machines, or whatever.
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.
The Mill was the opposite extreme.
> The Mill was the opposite extreme.
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.
Yeah, but RISC-V came out of RISC-1,2,3,4; it didn't magically appear our of nowhere. "RISC-V was developed in 2010 at the University of California, Berkeley as the fifth generation of RISC processors created at the university since 1981".
Also, RISC-V is not particularly innovative or groundbreaking. It's a standard Von Neumann CPU optimised for simplicity and modularity.
The Mill was (is?) a much bigger swing, with much bigger problems to solve in getting to production.
This is above my pay grade but since LLMs have become the 24/7 code writers, I started to wonder if our processing architecture could see much more innovation. I see light-enabled processing, analog processing and other headlines on posts/YouTube. Most are focused on inference though. But there is also the need to run generated code on cheaper, efficient chips.
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.
https://www.technewsworld.com/story/lessons-learned-from-tra...
I always wonder where will x86 be in 10 or 20 years time. As data paths widen for SIMD, how many can they possibly cram , such as more generations of wider and wider groups of instruction with different opcodes and characteristics.
Do you remember the 1990s everlasting arguments about RISC vs CISC? There were so many arguments (online and magazines) saying that "soon" RISC would eat CISC. And yet, it never happened. I'll be dead before the demise of x86. More likely: The computing landscape will get more complex. Probably ARM will become a legitimate competitor to x86 outside of handheld computing, and RISC V will become a legitimate competitor to ARM for single board and handheld computing.
I mean it did kinda happen. x86 is pretty much the only surviving CISC. Everything else that has come since 80s or 90s has been RISC.
arm is very much a cisc, arm iphones have instructions that correspond to speeding up JavaScript hot paths (FJCVTZS)
Also some GPU instructions are several times more complex than the most complex cisc instruction from the 90s.
I think you are confusing CISC with specialized instructions. We just ask 3 questions to decide if something is CISC or RISC. 1. Are the instructions 32 bit wide? 2. Can the instruction only operate on registers? 3. Does it use microcoded, multi-cycle state machines for basic instructions?
That's not the usual way to discuss CISC or RISC (and ARM fails two of the three questions anyways).
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?
> Probably ARM will become a legitimate competitor to x86 outside of handheld computing
Err..
Are Apple Silicon and Nvidia Vera and Amazon Graviton are considered illegitimate or non-competitors for some reason?
You are right! I didn't think about about Mac desktops. I was thinking that ARM is a second class citizen for Linux and Win32. X86 is still king there, but that will slowly change.
for starters... drop ballast
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?
This is my first time hearing about Vine - https://vine.dev/ I have to say the landing page is terrible, at least show an example of the language.
They've announced a playground [1] recently on their Discord.
[1] https://vine.run/
Am I missing something?
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:
This other version can run in parallel, but only because the algorithm was deliberately written that way: So the programmer still has to think about parallelism; the language just removes the need for threads and locks.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?
Bom dia, it's my understanding that there is no runtime. The hardware does all of the graph rewrites. If you look at their 'On Interaction Nets' post [1], it seems that part of the pitch is that many programs can be written 'naturally' and still parallelize well.
[1] https://tendrils.co/blog/2026-04-26/on-inets
The factorial can be calculated using a Taylor series, whose individual terms can be calculated and summed in parallel.
From the URL:
"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?
It makes a million times more sense when given the context it's found in https://vine.dev/docs/features/conditions
Tl;dr: Vine offers explicit versions of short circuiting and non-short circuiting conditions, but non-short circuiting is the default. The above explains that because it uses the `&` operator rather than the `and` operator.
Broken down further: Short circuiting means you can defer computing everything needed to know `c` until you have confirmed you need to know c to answer the comparison chain. If a < b then you might save a ton of work by not needing to ever calculate everything leading up to c. If a >= b then you've now held off even starting to find out what c was until you need to know what c is.
If you have a ton of parallel compute then it's not as big a deal to always compute all 3 in parallel at the same time, even if sometimes a lot of that compute was not needed to answer the question. The upside is you always finish in the shortest amount of time possible, even if c is a ton of work to figure out.
I think thats a poor example (either that, or less charitably, they're scamming investors).
They just described a common superscalar optimization thats been done since the 90s.
Vine sounds like it has a similar philosophy to Bend [1]. I'm sure it would be possible to compile Bend to run on one of these chips as well.
[1] https://bend-lang.com/
Isn't this basically a GPU?
Not necessarily, there are other kinds of accelerator designs like dataflow architectures or systolic arrays.
> This requires moving beyond the notion of shared mutable memory and linear instruction sequences.
Sure looks like it.
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.
> CUDA is a huge reason NVidia is so big right now. Their GPUs are broadly similar to AMD. Their software libraries are better.
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.
> it is the compiler to use it that is the hard hard part
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.
Yep, and they're probably simulating/emulating their CPU design on GPUs already.
Wasn't that what RISCV was supposed to do? apologies, dumb question
I think RISC-V is intended to be a simpler-to-implement processor that can also be used as a compilation target for existing languages, b/c it still shares many properties of x86/ARM (e.g. pointers, memory addresses, etc.). I don't think Tendrils' chips are intended necessarily to be able to run existing code, but instead will require Vine to be able to program for their chips.
Other than that, I don't think there's much relation between the two.
This is amazing!
How will this be better than RISC V?
Who do you expect to answer? It's a tiny future product announcement, it neither exists, nor is it a Show HN from someone involved
a man can dream
Have you seen the new CPU architecture? It's on Mill. It's literally on Transputer. It's on Rock with Sun. It's literally on AMULET. You can probably find it on Itanium. Dude it's on Tesla. It's a CDC STAR original. It's on E1. You can program it on E1. You can go to E1 and program it. Get onto E1 right now. Go to E1. Dive into E1. You can E1 it. It's on E1. E1 has it for you. E1 has it for you.
In all seriousness congratulations on finding $30 million to launder and lose immediately. Hope your Porsche runs good.
Really would like to understand how the mill got going and how anyone can see it progressing at this point. I know folks are working on it on the side but it's just bleh now.
$30M to either do nothing at all, or change the world.
The chip might be great but they really need to rework their overview blurb. I'm no CPU designer but even I know every single thing they mention like it's bold, new 'think different' stuff, hasn't been a 'new idea' since at least the 1990s. For example:
> 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.
How do I get people to give me $30 M to work on nonsense?
Step 1. Stop calling it nonsense.
> Sources say that the company is already discussing a fast follow-up raise that would potentially value the firm at more than $1 billion. Neither round has previously been reported. Benchmark declined to comment.
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!
According to article, his brother Jack is now on the board, and a general partner of Benchmark.
There is also https://en.wikipedia.org/wiki/XMOS which was funded by people behind the transputer.
I'm quite interested to see how this evolves. But part of me is still being sad, because hardware is rarely the bottleneck these days - as opposed to software.
it’s the Transputer again, or the Emotion Engine again, depending on how old you are
FTA:
"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.
Let's not call it a CPU if it doesn't have SoTa single threaded performancr
Maybe now the cpu arena is a patent graveyard instead of a patent minefield, some fresh developments can appear.
let's re-do the OS too. we only need about 10 syscalls. authorization is totally backwards (look how android runs a user per process).
Was about time we had another Transmeta.
Bet you they will turn into yet another ML accelerator company within the year.
TL;DR: it's basically Niagara/GreenArrays/etc again.
Not sure why this one will succeed where its forebears didn't.
They already got the UK government to give them some taxpayer money. Success accomplished, now it’s just mai tais on the beach.