VLIW Myths, Multiflow’s Rise, Itanium Lessons, Embedded Future

Name: An Interview with Josh Fisher | Inventing VLIW, Multiflow, Itanium, VLIW's Massive Success
Uploaded: 2026-04-30T23:00:51+00:00
Duration: 1 h 11 min 18 s
Channel: Asianometry
Description: Summary and key takeaways on VLIW Myths, Multiflow’s Rise, Itanium Lessons, Embedded Future, covering The VLIW Mythos Asianometry: Why do many people still

Asianometry

Apr 30, 2026

•

71 min video

•

2 min read

YouTube video ID: jgMUEg4v4IQ

Source: YouTube video by Asianometry — Watch original video

PDF

Asianometry: Why do many people still call VLIW a failed technology?

Josh Fischer: The biggest misconception is that somehow VLIW was a failed technology, which is a little bit crazy. It ships 12–15 billion processors a year in embedded devices, so the “failure” narrative only reflects its inability to displace x86 in general‑purpose computers. Pushing complexity into the compiler is a practical trade‑off; the compiler does the hard work, allowing the hardware to stay simple and power‑efficient while still delivering high parallelism.

The Multiflow Saga

Asianometry: What was Multiflow’s role in VLIW history?

Josh Fischer: Multiflow built the first practical VLIW system, delivering superior price‑performance on scientific code. The machines could dispatch 7, 14, or 28 operations simultaneously. The company raised $70 million but collapsed in early 1990 because it could not secure a next financing round. “Killer Micros”—single‑chip processors—made Multiflow’s multi‑chip, high‑power architecture economically uncompetitive. Strategic missteps, such as lacking a presence in Europe and Asia and a CEO focused on traditional P&L rather than high‑risk startup needs, compounded the problem.

The Itanium Era

Asianometry: How did Itanium’s approach differ from Multiflow’s, and why did it stumble?

Josh Fischer: Itanium tried to bring VLIW to general‑purpose computing but suffered from an “over‑the‑wall” design: hardware was built without deep co‑design with compiler teams. The massive installed base of x86 software meant that without mature binary translation, a new, incompatible architecture could not gain traction. Intel’s hardware team never gave Itanium the focused attention it required, leading to delayed and slow products.

Embedded and Future Applications

Asianometry: Where does VLIW thrive today, and what does the future hold?

Josh Fischer: Embedded systems—IoT devices, printers, base stations—are ideal for VLIW because they need low power, small silicon footprints, and predictable timing. Google’s TPUs, used for training Gemini, already employ VLIW architecture. Looking ahead, VLIW’s deterministic, highly choreographed instruction streams are a good fit for quantum‑computing pulse control, where precise timing is essential.

Mechanisms & Explanations

Asianometry: Can you explain the key technical ideas that make VLIW work?

Josh Fischer: Trace scheduling, a compiler technique I helped develop, automatically translates sequential code into wide instruction words, eliminating the “misery” of manual microcode layout. Compared with superscalar designs, which dynamically align operations at runtime and become power‑hungry as parallelism grows, VLIW shifts that alignment to the compiler. This shift lets the hardware stay simple while still achieving high parallelism.

Asianometry: Why is embedded computing such a natural home for VLIW?

Josh Fischer: Embedded computers are hidden inside devices—refrigerators, cars, printers—and they run a limited set of tasks. They don’t need the massive, pre‑existing software ecosystems that general‑purpose PCs rely on, so the compiler‑driven parallelism of VLIW fits perfectly.

Takeaways

VLIW dominates embedded markets with 12–15 billion processors shipped annually, disproving the myth that it is a failed technology.
Multiflow’s technical success was undermined by financing gaps and the rise of low‑power single‑chip “Killer Micros.”
Itanium faltered because hardware was designed without sufficient compiler co‑design, and the entrenched x86 software ecosystem blocked adoption.
Embedded devices benefit from VLIW’s low power, small footprint, and predictable timing, making it ideal for IoT, smartphones, and AI accelerators like Google’s TPUs.
VLIW’s deterministic instruction streams are well suited for future quantum‑computing pulse‑control applications.

Frequently Asked Questions

Why is VLIW considered successful in embedded systems despite the myth of failure?

VLIW powers 12–15 billion embedded processors each year, delivering high parallelism with simple, low‑power hardware. The myth stems from its inability to replace x86 in general‑purpose PCs, not from any technical deficiency.

What caused Multiflow’s business failure despite its technical achievements?

Multiflow could not secure a new financing round and faced competition from low‑power single‑chip “Killer Micros,” which made its multi‑chip architecture uneconomical. Strategic errors like lacking global market presence also contributed.

Who is Asianometry on YouTube?

Asianometry is a YouTube channel that publishes videos on a range of topics. Browse more summaries from this channel below.

Does this page include the full transcript of the video?

Yes, the full transcript for this video is available on this page. Click 'Show transcript' in the sidebar to read it.

Helpful resources related to this video

If you want to practice or explore the concepts discussed in the video, these commonly used tools may help.

Computer Architecture A Quantitative Approach Book Recommended

This classic textbook provides the foundational knowledge of instruction-level parallelism and VLIW architecture discussed in the video.

Amazon →

Fpga Development Board For Embedded Systems

Allows users to experiment with custom hardware architectures and VLIW-style parallel processing in an embedded context.

Amazon →

Compilers Principles Techniques And Tools Book

Known as the 'Dragon Book,' it covers the compiler theory and trace scheduling techniques that are central to the VLIW paradigm.

Amazon →

Microprocessor Architecture From Simple Pipelines To Chip Multiprocessors

Provides a comprehensive history and technical breakdown of how different processor architectures, including VLIW, have evolved.

Amazon →

Links may be affiliate links. We only include resources that are genuinely relevant to the topic.

Summarize another video

Full Transcript YouTube

I don't do that many interviews, but
when Josh Fischer emailed me after the
first VLIW video came out, I figured I
had to take a shot and ask, and to my
great pleasure, he agreed. Fischer is
winner of the Eard Mockley Award and a
pioneer of VLIW architecture. I consider
him a legend. Enjoy the interview. Note
for the video, my audio sort of desynced
about halfway through due to bad
internet, so I had to do some edits to
ensure flow and continuity. I also made
a few small cuts for pauses and whatnot.
I tried to keep as much as I can, but
forgive me for any errors. Now, on to
the show. Welcome to Asianometry. I'm
here with uh Josh Fischer, ameritus
senior fellow at Huelet Packard and
pioneer in VLIW. It was it's a real
honor to have you on, Josh. Welcome.
>> Thank you, John. It's an honor to be
here. Your video on uh VIW stirred up a
lot of interest, more than I've seen
personally in a long time for my own
work. BLWS has much more interest than
ever.
>> It's actually something I've been really
interested about because
um you know it it has a reputation and
then when I went through the the
literature and the documentation of the
work you've been doing and I thought it
was an amazing story and then when you
reached out to me uh it was incredible.
So, uh, you know, we have a couple
things we want to talk about, but I want
to let you do most of the talking, but,
um, how about we start off a little bit
with some some of the intro material
themes, like
what are some of the misconceptions
about VIW that we need to put on the
table first so people can get that right
off the bat,
>> right? Great, good idea. So uh the
biggest misconception is that somehow
VIW was a failed technology
which is uh a little bit crazy. It it
hasn't succeeded in general purpose
computing. That's a long story and
people have damned the technology for
that failure. But
right now there are every year
something on the order of 5 billion VIW
units sold and each of these units being
a particular chunk of silicon uh has
often has several VIW
processors on it and probably a
reasonable estimate and I'm relying on a
lot of AI help there. I don't have
marketing figures easily available to
me. Um, but probably something on the
order of 12 to 15 billion BIW processors
ship every year. And it's a little hard
to characterize that as a failed
technology. So that's I think the
biggest myth that really needs to be
exposed. You know even the units
five billion is like 15 times the count
of x86s
and 12 billion five times 15 billion 45
times the count of x86s. Of course
that's not the dollar count. Most of
these are very inexpensive because
they're embedded.
And you know that's a that's a whole
subject of how people regard embedded
computing compared to uh compared to
general purpose computing and I would
like to get into that maybe a little
later. And then you know there are myths
about uh VIW being bad because it pushes
the complexity into the compiler.
Uh it's actually good and we can talk
about that later. And then the company
Multilow. So I started the company with
two of my colleagues started the company
that uh produced the first really
practical
uh VIW
computer system and uh people like to
talk about why it died and uh there's a
lot of crazy reasons you know it's
because the compiler was too slow. It's
because the hardware was too slow. It's
because the business failed. I mean,
yes, that's why Multilo died. The
business failed. But people then damn
VIW
as a failure because that business and
further the Itanium, which is something
I'm sure we'll get into, especially
since you just released a really
fascinating video about the history of
Itanium. Um, we'll get into that a
little later. And then you know there's
the broad subject of what matters is the
generalpurpose computer as I said you
know embedded kind of puts in terms of
processors shipped kind of puts general
purpose computers uh at the noise level
and uh and then hardware versus software
big prejudice about that
I also since uh I thought a lot about
what I was going to say here I've been
retired for 20 years and haven't had my
hand directly in the field, though
obviously I'm still involved.
You know, I'm going to throw a bunch of
people under the bus when I talk about
what's happened in the history of LIWS.
And uh please don't take that as my
thinking. I didn't make a lot of really
egregious, horrible, major mistakes of
action and personality in the course of
this history.
I guess that's what I'd like to see out
of the way first.
>> Not bad. It was a good start. I think
like I I remember when I was uh reading
your literature basically said that you
you you ran a good you had a good talk.
You got a good talk going.
>> Thank you. Yeah. No, I mean I've always
been a good speaker and you know my
wife's book, my wife's fabulous book
about the history of multilow
uh giving an inside look into startups
which you very kindly gave such a
stellar review to in your VIW video. You
know, she talks about my having been
good at explaining things. That's the
nice way of looking at it. Good at sales
would be a different way of looking at
it. But, you know, I'd like to think
that everything I ever tried to do with
that skill uh came across as the truth
because there's my first not very humble
statement.
>> Let's start a little bit with like the
history of VIW, right? You talked a
little bit. I've already talked in the
video a lot of that, but like what
particular things that maybe that wasn't
mentioned uh do you want to start out
with? Like you talked a little bit about
embedded. I know DSPs will is a great is
a large part of that history like what
what's your what you know DSP first of
all people think DSP is a chunk of
hardware DSP is an application okay it's
simply an application when a computer
does or an electronic circuit does DSP
what it's doing is running an
application and people say oh that's a
DSP but it's running an application
called digital signal processing which
is incredibly central to our lives
these days. I mean I could go on and on.
So DSP has been around for a very long
time. That is DSP circuits or computers
to do DSP. And because it's an
application, you could run it on any
machine. Just depends on how fast or
expensively you want to do that. And
what people found was that by issuing
lots of individual operations like ads
and multiplies at the same time, they
could do DSPs very fast and with much
less electronics. And it was hardware
designers that did that. And there were,
you know, everything ranging to big, not
big, well, big by today's standards,
computers that were attached to things
like CAT scanners produced from a
company called Floating Point Systems
and, you know, high performance
uh actual computers that did scientific
computing from uh CDC and other
companies. And these all had the idea
that you would dispatch a lot of
operations at the same time and you
would plan that in advance and you would
do a fetch execute cycle on it. To me
that wasn't a computer because you
couldn't compile for it. It was the
hardware designers sitting and laying
out the circuit and the circuit happened
to have a fetch execute cycle in it. But
they they built it as if they were just
building hardware. you know this thing
should happen here, this should happen
there, this should happen there. And
when I came along as a graduate student,
I was working on a project that had
something called horizontal microode,
which was once again controlling the
computer using a circuit of the same
nature. And people handcoded them. And
there was a little bit of literature
about hey can we take the microode and
write it just as a single stream so that
we can begin to understand it and then
translate it into these wide words where
there were multiple things you would do
at once without your having to set that
up by hand. Setting that up by hand
which is what I was doing the second I
started working on this as a student was
misery. I mean it was all tightly
interwoven. And the analogy I always use
is that if uh it's as if you built you
did a jigsaw puzzle and there was a
little space enough for one piece and
you have one piece in your hand and it
doesn't fit that space. You know, the
next thing you do is you take the whole
puzzle and you just jumble it up and
start again because you couldn't unwind
all of that. It was too intricate and a
mess. And so I decided to try to
automate the process
of turning this sequential code that you
could actually read and treat like code
into this more circuitlike thing. And uh
there was a little literature on it, but
it was done by hardware people who as
bright as they were at designing their
hardware had no clue of the software
techniques you would need for that. And
fortunately I was at a university. It
was New York University but at a
mathematics institute called the Kurand
Institute. And that was the heart of
circuit of compiler research at the
time. And I recognized that this was a
job that was a lot like what compilers
do, you know, which translate one
language into another. And so I tried to
see whether it made sense to try to do
that. And I could see that the people
who were trying were a little naive
about the software aspects and what's
called computational complexity aspects.
And so I came up with a technique to do
it myself that was very different from
anything anybody had proposed that it
really works. And as a result of that I
knew that you could write even a
highlevel program. You could write
programs in C or whatever and then
produce these wide instruction words
from that. And I called that technique
trace scheduling. And then I realized
that I could apply that to these DSPs,
particularly this floatingpoint systems
machine, which was very popular because
virtually all the all the GECAT scanners
had them. I tried to do that and I saw
that the architectures of those machines
made the job of doing this translation
into wide words really impossible.
And so I said, well, you know, you got
to design the hardware with this in
mind. You can't just design the hardware
and then say, let's see if we can
compile for it. Let's see if we can
translate code into these wide words. It
just it's never going to work. And so I
came up with a style of computer which I
called very long instruction word which
had this hardware structure that already
existed, but it was something you could
and we did compile for.
That was by then at Yale University. And
so I named it VIW.
And uh I uh started building a machine
there because we had we paraded every
single manufacturer in to try to get
them to build one of these for us, which
was not entirely practical at Yale
University and uh or any university. And
uh none of them were they were all
fascinated by it. I mean, part of that's
my I guess my blurnie, but uh they they
really did uh show, I think, genuine
interest in it. They sure weren't going
to pump millions of dollars into it. You
know, it was just too risky and not on
their P&L to do that sort of thing. Um
and so, uh two of the guys working for
me and I started Multilow because we
realized we could never do that. We
wrote a compiler
and the main author of that compiler
actually it was his PhD thesis won the
best thesis in the world of computer
science award that year. It was a great
piece of work. So we had a compiler and
we could we it was a very plastic
compiler that is you could describe the
machine and it would generate code for a
machine described that way. Uh you know
how many of what you had for example put
together how many things you could
dispatch at the same time and you know
that was John Ellis was the gentleman
who wrote that. Um
the bulldog compiler was called as we
joked bulldog the Yale Yale Bulldogs.
That's the uh that's what the sports
teams for example are. And uh it was
very tenacious. We wanted to suggest the
tenacity and as we said also let people
know that it wasn't written at Harvard.
So um that's a sports competition. Neiel
and Harvard. So, uh, you know, we wrote
this compiler and we knew we could do
it. We we sat there and looked and we
said, "Look, we could build a machine
that probably, at least on scientific
code, get the best price performance
that's out there, period." And yet,
despite our having all the facts and
figures, we couldn't really convince any
mainstream computer manufacturers. I
can't tell you how many of them we
marched in. And it's funny because TI
actually wrote, they were we bared TI in
as well, Texas Instruments in as well.
And they actually wrote later, you know,
we saw this thing, we thought it was
nuts and we dismissed it. But once we
actually had to build the thing we
wanted to build, we came to realize that
was the solution that really worked. And
they did. They built the initial most
successful commercial
systems.
>> What was kind of at that time? So we
started multilow and that's a long saga
but that's the beginnings of
>> many supercomputers
many supercomputers. Yes there there was
a category of people often conflated the
two. There was a category of computer
called uh super minis. They were just
big minis and eventually the vax kind of
came to dominate that area. But these
were intended to be small supercomputers
that we would sell to people who needed
a supercomput but we would be a tiny
fraction of the price and give a very
large fraction of the performance which
we did.
Sure.
Well, we didn't really compete with Cray
directly. If people wanted to buy a Cray
and could afford a Cray, that would get
them the fastest throughput on their
applications. So, they would do that.
But, yes, Convex and 30 others. I
actually had a list. I think it was
certainly in the well into the 20s of
people who were trying to sell into that
price performance space. We had the best
price performance through most I think
all of our history on the standard ended
up measures that kind of thing.
>> Looking back on it, what precisely you
just mentioned earlier like you know
what it all these reasons that why it
died and all the complexity or whatever.
Looking back on it, what was your
reflection on what happened there?
So, you know, the first thing I have to
say is that there's this ziness and I I
can't read social media comments about
VIW anymore. There are lots of them. And
of course, your wonderful video grabbed
a whole bunch more. People
people somehow think that a technical
business a business failure implies that
the technology that the business was
narrowly described as being was a
failure. It's just wrong. I mean you can
have fabulous technology and have your
business fail. Ulow had fabulous
technology really by any measure and our
business failed. And it failed for
totally understandable reasons. There
was no great mystery. Look, we we never
lost sales because of performance. Just
didn't happen. We were fast and cheap.
We weren't as cheap as we should have
been. That's a whole other story. That
was a, you know, a marketing question.
But we were as fast as we should have
been. And we ran what people needed us
to run. We failed because we uh not even
we didn't even run out of money in fact
but we essentially ran out of money in
the sense that there was no prospect for
financing a next round. And the reason
there was no prospect was because as you
mentioned in your video Killer Micros
had come along. you know, they couldn't
compete with us, but what they could do
was put an entire fast computer on a
single chunk of silicon. And you
couldn't do that with a BLW because to
get as much parallelism as we got needed
a heck of a lot of functional units. You
know, we our three machines were they
were really one machine that you could
expand were
uh doing seven 14 or even 28 operations
at the same time. That's a lot of
hardware and you just couldn't. It was
years before you could fit that on a
single piece of silicon. Finally,
actually Philips did it first. Put a
meaningful VIW on a single piece of
silicon. And those those chips were
going to cost a tiny fraction
that were going to and did cost a tiny
fraction of what we cost. And just as we
were trying to undercut Cray with much
cheaper hardware and a meaningful
fraction of the performance, those chips
had meaningful hardware and a fraction
of the performance, but far cheaper
hardware. So, you know, we we were just
not in a position to um Let me adjust
this camera. I keep staring at you as I
should and uh I'm probably looking
sideways a lot. Um so we really failed
because we had no prospect of a next
round and we actually closed the
company.
This is an error on my part though my
part the CEO story uh well described in
my wife's book.
>> Uh and uh the board closed the company.
Well, we still had enough money to not
have it be a very graceless failure. So,
we were able to pay off the creditors.
We were able to pay the back salary. I
learned that in the state of Connecticut
uh where we were um a uh not paying
backation pay
is a felony on the part of the principal
company. Oops. So, I got to read in the
front page of the New Haven Register
whether I would be going to jail or not.
Um, because who took vacations? You
know, we were a startup. We're working
80 hours a week. Oh. Uh, anyway, I
wasn't worried about that. The venture
capitalists would certainly never let
that happen.
>> You mentioned that it's not rare to we
were a very notorious startup. It was
always, you know, one of these companies
to watch
>> full page say about you most popular
business publication at the time. You
know, our closing was in the Wall Street
Journal and it, you know, it was a big
deal and very visible. So, I wasn't
going to jail.
>> Yeah. I was owed a lot of avocation pay
too, of course.
Crazy story.
Sure.
Well, so I'm sorry, Tanya. So, uh, no,
no, we Why is it that we couldn't have a
next round of financing? So killer
micros were certainly the the uh the
main reason and I would say
overwhelmingly dominant reason that we
couldn't get people to invest people you
know investors really caught on to the
fact that there was a big transformation
coming you know processor chips were
going from the very slow things that you
know 486 say that PCs ran on to much
more powerful things and there were
these you know there were the
workstations Sun and Apollo
workstations. They were kind of
demonstrating that you could get a lot
done,
you know, nowhere near the level of
performance we had, but enough to make a
big dent. And it just didn't make sense.
And then everybody always regarded our
technology as risky.
It it never mattered how much we
demonstrated an absolutely solid
computer. I mean, it really was. It ran
out of the box and it ran perfectly. I
mean it was a really amazingly educated
uh system, amazingly engineered system
but you know this was weird and it was
software behind it as well. People are
very suspicious of software versus
hardware. You know I always think back
on the history of mental illness. You
know, some hundred years ago, people
would say, you know, get a hold of
yourself, man. You know, not recognize
that it was mental illness was real
illness because you couldn't see it, you
couldn't feel it, you couldn't see the
effects except people would act crazy.
And it's like that with software. You
know, hardware, you see it, you feel it.
Okay, you don't really know what's going
on, but at least it's tangible. It's
something you can hold in your hand.
Software is ephemeral and a way off
somewhere. And uh
you know people were always easily made
suspicious of it and our competitors I
have to say we really had one competitor
that mattered in the marketplace and
that was Convex.
Um you know they had far faster hardware
than we did which is yet another subject
that we should talk about. Um
and even though we beat them on price
performance usually at the customer's
site convex they could understand it had
the same general style of architecture
as a gray you know a vector machine and
they used ECL technology I don't even
know if these terms are widely used
anymore but they used ECL technology for
their hardware and we yeah emitter
coupled logic is what it stands for and
we used TTL which was a very very big
generation behind. And people say in
fact that one of three or four main
reasons people incorrectly say we failed
was that we had slow hardware. Well,
what we had was a machine that could
dispatch
28 operations at the same time and a
company that had only so much money
because once again wasn't easy to raise
money uh to build such risky technology.
It's remarkable to me that we were able
to and the um
the the fact that we were building this
machine that was so different from
anything anybody had built and so really
extreme
and with so little money and just a
handful of really really bright people
true computer scientists who understood
what they were doing better than your
typical engineer does. You know, if we
had tried to do that in ECL, we would
have been years later to the market. And
that that in fact is one of the mistakes
Cyrum, which never did sell anything,
made was to build their machine out of
fast enough
uh circuits. So
the other at the time VIW with Bob, my
future after that colleague Bob Ralph,
an absolutely wonderful person who died
too young. um you know building in TTL
was the only sane thing for us to do and
despite building in TTL it was
incredibly hard to build. So people talk
about the failure was slow hardware and
implying that of course it was a dumb
machine because it just does what the
compiler tells it to do. The combination
of that and the and the slower circuitry
makes people think that somehow this was
something we should have done
differently. But in fact, it was an
absolute beast to engineer. And when you
have buses the size of our buses to push
around the data you needed for that much
computation simultaneously,
that that was really a massively
difficult piece of engineering. And I
think most engineering teams wouldn't
have pulled it off as a first attempt to
do anything like that without 100
failures before us. But they did. And it
was a beautiful machine when they were
done. So we had risk and and so you know
there was convex in particular spread a
lot of FUD you know fear uncertainty and
doubt uh in the marketplace we always
met them on the marketplace. One place
we didn't unfortunately was most of
Europe, Germany and most of Asia which
at that time means Japan. Um, we didn't
have a presence there at first, which
was a horrible mistake, one that I
regret not having fought harder to
correct. We did have a distributor in
Germany who uh Dameler Bentz who uh saw
I guess the Business Week article and
approached us and they were very
successful but they had to compete with
Convex as we did in the states which had
markets where they could sell machines
at list price all over the world and
they sold a lot all over the world and
that allowed them also to more deeply
discount in competing with us. So that
was a major error on the company's part.
But yes, and Convex spread a lot of FUD.
You know, here we've got this proven
technology and it works great because
it's what's in the Cray. You know how
great the Cray is. And here are these
guys who are, you know, coming from
another planet. You really want to bet
your job on buying one of these crazy
machines, which was a pretty healthy
argument in the marketplace.
What could you have done better to
market the technology?
>> Number one, we should have uh made sure
that our one and only real competitor
didn't have much of the world to compete
against us in without our presence. So
that's one. Second thing, so one of my
two founders, co-founders, John
O'Donnell and I tried very hard to get
our price reduced for a long period of
time while we established a large
customer base and to spend more on
hiring. Heck, we could have hired math
PhDs who were sadly a dime a dozen at
the time, probably still are. Not as bad
as philosophy PhDs, but uh you know it's
a tough area for a brilliant person to
find good employment in. And we should
have shipped people on site with the
early machines. Problem is uh our CEO
who we really had to hire and was great
at first for us getting us to be a real
computer company. Um, our CEO came from
the very old world of NCR minicomputers
and he had a picture of P&L statements
and how you make a profit. It was just
not appropriate for such a chancy
seeming technology
and couldn't convince him. I naively did
not go to the board and work my behind
off to get us to lower the prices at the
outset.
guarantee take the machine back if you
don't like it. Uh and and ship a tech
support person with the machine at first
because people were frightened. But
look, it's crazy. People were issuing
32-bit instructions. We were issuing
thousand bit instructions. It was just
like nothing they'd seen before. So that
those were some of the marketing
mistakes we made. We had an amusing
marketing mistake though. I think in the
end it was a success in that some of our
guys came up with the slogan no vectors
and uh because we were competing against
vector machines. So we had buttons and
coffee mugs and they were very popular
among the scientific application
customer crowd. If you'd go to a trade
show they'd all be my wife tells this
story in her book. They'd all be
wandering around with grins wearing no
vectors buttons. But of course vectors
were what they did. It wasn't a perfect
marketing slogan. We got away from that.
We hired a guy who, like so many
multiplow employees, turned out to be
enormously successful. After that, he
was already well on his way named Brian
Cohen, who was really a terrific
marketing person. And another mistake I
made was allowing our CEO to our CEO
didn't like the guy because he was, I
think, too unconventional, but he was a
brilliant marketeteer. He really was.
And uh you know that was probably a
small factor but that was the sort of
thing that was a problem. You know we we
kind of glued an old-fashioned CEO who
was who was terrific or as I say getting
us to have our engineering be uh on the
mark and like a real organized company.
None of us had business experience
really and and so that was tough. I
couldn't finance the company with me as
CEO. that just it was pretty evident
very quickly that that wasn't going to
fly. It's too bad. I think I could have
done it, but couldn't convince people
that I could. And so we had, you know,
we had a merge merger of good
engineering practice and a lot of that
sort of thing. You know, again, in my
wife's book, she tells the story that,
you know, Don came to our house. Don
Ectal was the gentleman's name. Um, he
came to our house after he agreed to
take this job. And the first thing he
asked me when was when is your weekly
staff meeting? that staff meeting, we're
20 people. If there's something we need
to do, we get together and do it. But it
just it was just a whole different
outlook. Also, I'm plugging my wife's
book a lot here, but it really is a
fabulous read. She did an unbelievable
job of giving a view of startups that
you just don't see anywhere. Um,
you know, the I think one of my big
mistakes was, you know, even though I
wasn't in control of the assets when we
made the decision to close the company
down, I think if I had been forceful
enough, we could have done a far better
job of that. I was exhausted. We were
all exhausted. We had we had worked so
hard on this project. Everybody was
exhausted. And we closed the company
down when Dak Digital Equipment uh
turned down the deal we wanted to make
with them. Uh which would have been a
broad marketing and financing deal. And
uh you know they turned it down because
they would have had their first
quarterly loss loss in their history if
they'd done it is what they told us. But
whatever, there was a competing project
within deck deck 9000 which was not a
success and eventually the company
tanked for that and uh compact bought
them. Um
so when we closed what we should have
really done, look here's next computer.
If you want a really good example of why
uh we had $70 million in financing in
our lifetime, Next Computer was started
by Steve Jobs when he was canned from
Apple around the same time as Multilow.
And so he started this company called
Next, Little E. So N XD. Um and uh so
already showing that his marketing was
better than ours. Um so uh you know he
raised 70 million, not $70 million. And
he couldn't make a go of it. And the
difference is that he had a fabulous
asset which was built the operating
system that ultimately Apple needed
and I guess not surprising given the
connection. And Apple bought that
operating system for enough money to pay
back his investors. So they didn't they
didn't lose money. I think they actually
made money out of it, but they closed
down by selling their assets in a sane
and patient way. It was patient. It took
them a long time. They had competition
for that operating system that Apple
needed. We had a compiler. That
compiler, we had a lot of VIW
technology, much of which we couldn't
own because it was style, not not a
thing. Um, and you it's hard to own
style. Uh but we had a lot of little VIW
technology and that was nice but
>> uh hard to sell. It was not nice. It
some of it was downright brilliant but
it was hard to sell. The compiler was
something that in fact got used all over
the place in the industry afterwards and
we sold a lot of copies of it. That is
the technology rights not the physical
copy sold the technology rights to use
that compiler to a whole lot of people.
And I think we could have raised an
awful lot more money about it, money
selling it, marketing it properly. I
think we could have even possibly kept
the company alive and moved the ECL
hardware that we were well along in
making that would have genuinely blown
convex out of the water because they had
nothing. But we didn't. We were tired I
would say and we left it to the business
side to sell the compiler
sell rights to the that was bad. So you
want to get on to Itanium. So look there
have been there have been four attempts
to put VIW into the general purpose
marketplace to replace what was on the
desktop and they were multifflow and cy
drrome.
uh Trans Meta, Itanium. Transmeta had a
VW chip, you know, it was after you
could build one in a chunk of silicon
and uh they wanted to use emulation, I
guess, maybe some binary translation,
but I think largely emulation to emulate
an x86
and uh they failed. But they had a VIW
architecture trying to do that.
amusingly guy the technical guy who
really started the technical side of the
company uh was a VIW very visible VIW
skeptic for a long time. So uh there
have been a few prominent instances of
that. Um so they failed and then
itanium. So I guess I can tell you my
uh Josh Fischer knows everything and
everybody else is wrong story about
itanium here. So, multiflow failed in uh
early in 1990. Drrome had failed 15
months before we did the other VIW
company started by Bob Ralph. Um the
first time we exhibited a uh multiflow
trace was at a supercomputer meeting in
Santa Clara in 1987 and Cyro was there
with their hardware and they had been
very much more secretive than we had
been. Abrao by the way once told me Bob
Rao who is a wonderful philosopher once
told me that he learned it doesn't
really pay much to be secretive because
you can't even pay people to do your
ideas to take your ideas.
Why pay the cost of secrecy? Anyway,
they have been very secretive and we had
no idea what we were going to see and
they were you know a few booths away at
uh this super conference. first really
big supercomputer conference I would say
and all the many super companies that
actually had hardware there were just a
handful of us at that point were there
and we looked at the machine right away
we said oh no problem it was a big hot
ECL beast
and because it w had to be big because
it was a VIW technology so that implied
large quantity of stuff to do and they
were doing it in ECL which required a
large quantity of space power and heat
cooling. So we looked at that but on top
of it we let people run their
applications on our machine. You know we
ran Unix. We had our compiler. Our
compiler wasn't as slow as people
imagine. Uh and we would demonstrate
lots of mainstream scientific
applications which uh Cyrum didn't have.
There was another problem, I'll get to
in a second, with side drums hardware.
That was uh that was very complex even
for a VIW. BIWs are simple, but that was
more complex. So, we looked at it and we
said, "Okay, we don't have to worry
about all of this with Sydrome." And
they never did sell a unit. And it's too
bad. I mean, Bob Ralph was an absolutely
besides being one of the literally
finest human beings I have ever known,
and I'm not just saying that lightly, he
really was amazing person. and from
South India who got a who got a job at
uh
at Champagne Orbana. It was the first
time he came to the states and he told
me that uh he got off the plane and
people said, "Oh, I'm glad you've come
here with such a nice sunny day." His
reaction, son, where what? So
anyway, but they they had that machine
and they had failed and Bob joined HP
Labs and HP Labs and now you've told the
story quite well in your Itinium video,
the Itanium video that you uh released
just a couple of days ago,
>> right?
>> Um Labs had wanted to replace the PA
risk processor
with something more powerful, a 64-bit
processor. and Bob had joined HP Labs
and I think the motivation on both
parts. HP's motivation was here's this
architect and uh he could help us with
this and Bob of course wanted it to be a
VIW because he was the other leading
proponent of VIWs. He had a rather
narrower modular scheduling look the IWS
but that was a real contribution to the
academic effort and uh he spearheaded a
lot of the design. 15 months later when
Multilow died I looked for a job. Now, I
always expected to be a college
professor my whole life and uh I looked
for academic jobs, but I also looked at
a couple of industrial jobs and HP
uh made me an offer. The project sounded
fabulous. I loved the offer. I could
stay in Boston
uh moved from Connecticut to Boston, but
that was fine. uh stay in the east coast
where I wanted to be, where my family
was, where we felt most comfortable and
commute and maybe spend summers for a
few years as I did at HP Labs in
PaloAlto and you know Bob was there and
I was prospect of working with Bob was
an attractive one. So that was a great
job and it really was. I the day after I
started work I was building stuff was
programming was doing experiments and if
id taken a job as a college professor
first 18 months would have been raising
money which I was quite tired of at that
point because that's you know 150% of
what I did at Multiflow unfortunately
got there and this project had already
been going for some time I was basically
handed a manual here's the architecture
And
I blanched. I mean, I I was really
unhappy when I saw that architecture. It
It really violated all of my principles
of what a VIW, never mind any computer,
should look like. It had
>> so much stuff in it. And all that stuff
was going to be very hard to compile for
in my opinion. And you know, it's
typical in the world of computing that
people build hardware and then throw it
out to the compiler guys over the wall
and say, "Hey, compile for this team,
would you please?" Uh, you know, it's
just not code design. And you know, you
talk about John a little with s
with the iteration of supercalar he was
involved with. He was a real proponent
of codeesign
as were we obviously at multilow. We
actually built the compiler first at
Yale and then went on to that.
Architecture was just something I felt
was just needed fixing. And I tried my
hardest basically just to get stuff
stripped out of there. And I really Bob
and Bill Warly, another wonderful
person, uh,
>> who I I'll now throw under the bus. Um,
they they were really very insistent
that this is what the architecture would
look like. And it was really too late to
do anything about it. And so I simply
right away
uh
decided I would get involved in more
basic research about VIWs. But I did
throw myself and by then I had started
after a couple years I had started HP
labs in Cambridge, Mass. And uh I uh got
involved in helping us finally get a
compiler at HP for this thing and that
was a mess. There were competing teams
from Exapalo which HP had bought and
Certino where they did their compilers
and people at HP labs and some of my
guys were uh I assigned some of my guys
to work with those teams and it was
really not something that fit my desires
of what the LW would successfully look
what my desires of what I wanted to
spend my time on. And then I moved into
embedded myself and the majority of
Cambridge labs of HP labs Cambridge into
embedded. So right away to I now mind
you I have to say before I uh let myself
off the hook here. I went to the first
HP Intel meeting and yeah and I was
really very excited about the fact that
a machine that was for all practical
purposes a VIW was going to replace the
x86. I mean, wow, what a credential for
my technology and what a wonderful thing
and I thought it was just great from
that point of view. However, I felt
about the architecture and the ability
to compile well for it and the effort
involved everything about the
architecture. Uh, boy, lucky me.
Everybody's going to think I've, you
know, done this magical thing. And
especially after, you know, Multilow's
disappointing failure. That was a great
thing. you could send me anywhere to
talk about how great it was and I would
happily do it. Um, but it wasn't how I
really felt. You can understand. I mean,
I I let myself off the hook here. Of
course, that was a wonderful thing for
me if that had really worked. the
computer museum. We had donated a
multiflow trace to the computer museum
and uh they put it right in their lobby
and the curator would take people on
tours and he'd say here you can see this
is the future of computing right here.
So you know
that was pretty heady stuff you know but
no it's not how I felt about that
architecture and I went into what was a
very successful effort and embedded
>> after that and you know eventually after
trying to get HP to uh build a VIW chunk
of silicon which HP wasn't really well
equipped to do that um we partnered with
ST Micro electronics X which was well
equipped to do that, the Italian French
semiconductor outfit and uh you know
that effort led to both the
ST241 family which zillions of were sold
into cable
box tops, cable set tops, uh etc. and
were used in, you know, base stations,
cell base stations, a million other
places. And then HP used it in our
printers, which was my initial goal. So,
uh, itanium,
sorry, you asked about Itanium and I
went off on personal stories. So, look,
itanium was
a system that, you know, and you could
read Bob Cwell, who was one of the
brilliant multiflow engineers after he
got his PhD.
um uh read his Pentium Chronicles or any
of his oral histories, get a lot more
sense of it. Look, you know, the whole
question of using a VIW
in general purpose, especially the
general purpose of
the 1990s,
the later 1990s, as opposed to when
Multifflow was in the 1980s, there was a
massive application base and by then of
stuff people expected to do with their
computers and to have any system that
you need to recompile for stopped being
really practical. ical by the 1990s.
You just that just didn't happen. There
weren't companies that really succeeded
that way. Now, the ARM 64 is on the
desktop and came along without ARM
having a big installed base, but they're
able to do the x86 through emulation,
binary translation. Those are
technologies that really were not mature
at the time. And so Titanium tried to do
that with hardware that made emulating
an x86 difficult.
They
I believe that the hardware team doing
the itanium was not where Intel's effort
was really centered. However much they
talked about it as the future and you
know the product was late slow on x86.
The extension to 64 bits was not really
x86. it was something else and then you
had to do emulation binary translation
still not very mature you know there
were a million strikes against it I
don't know anything about the marketing
efforts and the business efforts except
what I've read no inside information for
IP reasons I built a firewall around me
and my embedded group and my core
research group and theanium efforts
because that wasn't HP anymore more and
and so you know I'm really not a person
qualified to talk about why tanium
ultimately failed but I do think with
the big installed base there was it was
going to be a very very difficult thing
to do an x86 replacement with that kind
of technology whether VIW can ever be in
general purpose computing oh you can't
count it out but you know if uh
if draft kings are that big Hong Kong
betting consortium. What is it? HJ Hong
Kong Jockey Jockey Club. Uh, ever wanted
to publish a line on it, I'd bet pretty
strongly against BLW ever being in
general purpose for as long as we still
have general purpose computers, which is
another question.
>> I talked, you know, talked about
Itanium. We talked about multiflow. And
I think something you've been getting at
now is the embedded stuff. And I think
to set just context for the you for the
viewers and all that, what is embedded?
What does that mean? And like what is
>> absolutely cases? So embedded is the
computers that are built into things.
They're not the user does not directly
knowingly use the computer. The user
uses his refrigerator uses their
refrigerator or us drives their car or
now you know there are any number of
processors in those devices more so cars
than refrigerators. And you know there's
now the internet of things. Uh the
concept's been around for I don't know
25 30 years maybe where there would be
computers all over the place in things
you wouldn't necessarily expect to have
a computer in and doing computery kind
of things but built in in a way that the
user doesn't see the computer. The user
just uses the device. So it's things
embedded in a device rather than exposed
to the user. And in people's minds, once
again, this is now the hardware software
intangibility question. Here's another
intangibility question. People see the
computer they're using and now the phone
they're using. Whereas
the built-in embedded computers, they
don't see. So it's not really on their
table. So, one of the reasons people
think VIW has failed is because it
failed in the computers that it they
could see. But the
incredibly greater number of computers
that we have in our world in 2026
are BIW as much as anything. I mean,
it's really dominant force now in BIW.
As I say, 12 to 15 billion computers
shipped every year is probably a good
estimate of that. You know, lots and
lots of companies that we know about
have VIWs and you probably wouldn't even
know having heard about their sales and
what where their computers are found.
You wouldn't know they were VIWs.
Internet of Things right away is just a
huge market. Those are you know
tensilica well cadence tensilica and sa
you know those companies ship billions
of computers that are viw there you know
8 and nish issue is a common number you
see around which is sort of a sweet spot
um and you know they do it because the
advantages of liws
are
paramount there low power
small
statically pred predictable behavior so
you know what's going to happen when it
happens in advance. The competing
competing architectures that have this
dynamic behavior like supercalers and
you know the x86 has the same dynamic
behavior they change their timing a lot
on the basis of what's going on. So
they're very unpredictable whereas PLWS
have very predictable timing and that
turns out to be a big benefit along with
low f power, low heat and uh low amount
of silicon for the parallelism you're
getting are huge advantages in embedded
and that's why now we're seeing the
internet of things huge volumes we've
got you know they're hidden away in your
smartphones all over the place Bluetooth
circuits and a million other oops
Bluetooth don't want to get charged with
that. Um,
have you been finding Bluetooth gets
more unreliable as time goes on? Uh,
so, uh, smartphones, they're in storage
devices, cars have lots of VIWs in them
typically these days. You know, TPUs and
MPUs now AI, Google's TPUs, they moved
to VIW from not being VIW. the TPUs are
the are the huge massive computers that
they train Gemini on are are all VIWs
now. Um there's just so many markets
where the advantages of VIW make sense.
You don't have to fight against having
to rebuild a massive installed base
which is a very very hard thing to do.
Probably what killed next for example
despite their $170 million. So, you
know, that's so that's the embedded
world. I say we I have nothing to do
with it anymore, but uh there was some
retrospective stuff that TI contributed
to, but I didn't really have anything
directly to do with them, only that they
when they built their I guess TI 6000,
if I'm remembering right. Um they they
you know, they built a VIW and credited
their visit to us at Yale when they were
on that march of manufacturers as being
a big part of that. But I had no direct
relationship with with TI. All we did in
my lab, I say all because it was a huge
success as far as HP was concerned. I
originally wanted to put it in printers
because they have to do this
rasterizing. You know, they have to turn
whatever you give it into a bit map in
order to print these little millions of
drops of ink they eject every second.
Sort of unbelievable technology in
inkjets. Um, and laser printers too. Uh,
and plotters were in Barcelona. Probably
still are. I haven't kept up. But you
know, these big 54 in printers
uh that architects and designers would
use. uh they needed to do a massive
amount of rasterization and we wanted to
build a chip for them to do that because
we could uh
bring all the advantages of Eliw to that
embedded space. So I tried to do that
with HP and uh HP couldn't build the
hardware ST did. ST marketed it as the
241 which I mentioned before was a
tremendously successful product. That's
really all I personally did with
embedded. I tried to do a few other
things. I have an amusing story to tell
you. So early Fiorina's next person I
want to throw under the bus. uh sorry
recurring theme was hired I don't know
if you know this name but she was hired
as the HP CEO to replace Lou Platt and
there are endless stories I could tell
about Carly
she uh
she did some things really really well
she integrated purchase of uh compact
into HP which is probably ultimately her
undoing from a cultural point of view
you know mergers are really tough And I
have my Fischer's law of mergers and
that is when two companies merge the
company with the worst culture turns out
to be the dominant one that emerges from
it. Um you can see that with airlines
all the time. So, uh, really did a lot
of good things, but she did, in my
opinion, tend to hire yes men. And, uh,
in marketing, she did that in my
opinion, and sorry to slander now, an
entire class of people. Um, I had the
brilliant idea, and I think it was
really a good idea, that because we
could do streaming media faster than
anybody else on the planet, because this
VIW technology was perfect for that. We
were the only ones really equipped to do
it. We knew so much about the
intricacies of VIW technology that at my
lab we started building this chip for
the printer people and I said you know
this was 19 or it was 2000 maybe I
guess. Yeah 2000. It was when the
convergence was happening. I guess you
talk about that in your uh PDA
predecessor to smartphones
video. Another really good video. So the
digital convergence was on everybody's
mind and people kind of knew there would
be smartphones. You know I Apple didn't
invent the smartphone. They just came
out with the first really successful
one. Um
but you know lots of PDAs were going in
that direction. To me we had a massive
advantage. we could do all of this
uh media stuff when nobody else could
and we could put it into a phone and HP
already had both the Jonata and IPAC
uh which was a compact PDA. Um they had
they had the hardware framework for it
and it would just be a matter of
sticking in VIWs as embedded processors
inside this thing and then we could do
movies. Nobody else could do movies. we
could do. There were a million things we
could do that nobody else could really
do well and we would get a huge jump on
what was obviously going to be a huge
market. I mean, couldn't have foreseen
what cell phones would become in
society, but we knew they'd be big. So,
I was very excited about this and I laid
it all out. I laid out what the hardware
would look like. I laid out this long
list of applications that we could run
that, you know, are not very different
from what a smartphone looks like today.
And that was not a piece of brilliance
on my part. Anybody thinking about it
would know that the what was really
unique though was that we had this
ability to do it now and not later. And
everybody else would have had to do it
later as indeed they did. So the
marketing people I was told well you
know you got to get this approved by the
marketing people to actually spend money
to build this thing. So I went to the
marketing people and these were the
whole marketing department was newly in
with this new regime and g whiz the
response I got back was no no that's not
what's going to happen. What's going to
happen is people are going to buy
individual devices. If they want to see
movies they'll buy a device that shows
movies in their hands. If they want to
do language translation they'll buy a
language translation device. if they
wanted software the idea that you could
do all these things on the same computer
was once again not something they
understood so I didn't get to do that uh
so the kurant institute so karant was
this brilliant student of Hilbert who uh
left Germany in the 30s he was a Jew and
not a good time to be in Germany and so
NYU attracted him by building an
institute a math institute around him
which for applied mathematics was uh uh
probably the best on the planet during
his tenure and the NYU where I was a
student computer science department spun
out of that and it was actually tightly
integrated with it rather than with any
engineering school and because of a
gentleman named Jack Schwarz
it was uh compiler heaven. So Schwarz
and the same John uh wrote a
tech report on compilers in the early
days of compiler optimization that was a
golden handbook of compiler
optimization. It was really very much
the state-of-the-art.
And uh Ken Kennedy, one of the handful
of top researchers in the history of
compiling came out of there. He was
Jack's student and the atmosphere at
Kurrant was one of compiling. It was
really a lot of what Kurant did for
research. And so, you know, my education
was aimed in that direction. And then I
worked on a hardware project where we
tried to build this machine
and I had a p the perspective of
somebody building hardware but was
fairly expert in compiling. I really was
a unique position to be in. There
weren't other places quite like that. It
was just a lucky stroke for me that that
was there. Well, I mean general purpose
computing these days needs a new
application base. if you have an
incompatible architecture that can't do
x86 and the fact that viws have
more compiling for the application
writers to do when they want to run on
your machine and for a new machine there
isn't a lot of incentive like with
itanium there wasn't enough incentive
for all application writers to sign on
because it was expensive for them to put
out a new version of their app when
there weren't customer for it. So, not
much to say about general purpose except
it's certainly far far less of an easy
market for VIWs. Betted is far easier
because tends to have much less of an
application need. You know, there's
handful of things you have to do. Mind
you, VIWs,
you know, the ST241 could run Unix. Here
was this thing that people were putting
in their set top box, but it could could
do anything. It was perfectly fine
computer, but nobody nobody tried to
sell it as a general purpose computer,
of course, because you would need this
massive application base to make it go.
And that was certainly one of the things
that harmed Itanium. People talk about
the compiling slow as a disadvantage of
BIW. And it's not a disadvantage of BIW.
It's a disadvantage of having to do a
lot of things at once.
And you know if anybody could ever build
a supercaler which does the work of
aligning the operations that you want to
dispatch at the same time does the work
of figuring out what to dispatch in the
hardware. The difference between VIW and
supercaler from this point of view is
that the hardware eventually has too
much to do to make it profitable to uh
issue so many things at once. But if you
could do that and it were practical, you
would need the same
depth of compiling to expose that to the
hardware because the hardware is never
going to find that much all by itself.
So I don't know if that makes any sense,
but compiling wasn't a an Achilles heel
of the LIW. It was simply if you want to
get that much parallelism to run a
single stream program as fast as you
possibly run it, which is what you want
to do most of the time, uh
you need that much compiling to find the
parallelism. It's as simple as that. So
the idea that it sort of threw a
disadvantage is that it threw the uh
work onto the compiler and that was
somehow bad is just silly. I mean it's
the price you pay to get a lot of
parallelism and it's been the most
practical way. That's why it's doing so
well and embedded. It's the most
practical way to go fast right now. Uh
first of all it's very different. So
people generally felt that uh
uh if this were really practical
somebody would have done it. I think
that really was the attitude that people
had about it. And and then it's, you
know, as I said, it's this weird, you
know, be behind the scenes thing. It's
very hard to explain how it works.
It's it's just it's very abstract, you
know, it's just not doesn't fit what
people people expect. And you know I
read for example on social media which I
avoid now when it comes to VIW. I read
uh that multilow failed because uh it
compiled too slowly or multilow failed
because the hardware was too slow or
these were never factors in why multilow
failed. But I think everybody wants to
concentrate on the technology. there
were much bigger factors that had little
to do with the technology itself.
But uh you know the BLW you know has
proven its worth that's for sure in
terms of an architecture that gets high
performance at low cost. you know, I
don't think there's anything else on,
you know, single stream applications. I
don't think there's anything else that
comes close. And I think the increasing
by large amounts yearbyear success in
embedded shows that it's just that the
general purpose marketplace is a very
different beast because of if nothing
else application uh bases needing to be
replicated. But today, you know, I think
if somebody tried to do what Transmeta
did, put a VIW on silicon, make it
cheap, rather than building the kind of
circuits we had to build at Multilow,
um, and use today's emulation binary
translation technologies that are so
much more mature than anything that was
around in the 80s and 90s. I think, you
know, they might very well have a good
chance of succeeding at it, building
cheaper hardware that could go faster
than the normal desktops can. You know,
somebody tried to do what it was doing
was trying to do, but you know, they'd
have to do it right. First of all, I'm
not convinced itanium did it right as
you heard. and uh
you know they'd have to have a lot of
money behind them to convince whoever
really does need to recompile because
emulation and uh binary translation
wasn't fast enough. But I don't know,
you know, but reflecting on it, you
know, to me uh in my now old age, um VW
has been successful beyond my wildest
dreams ever. I mean, even when I maybe
thought it would take over the desktop,
uh, you know, that would have been from
an ego point of view far more successful
because everybody would know about it.
Here, it's technically so successful. I
never imagined it could be that
successful. I mean, that's just a lot of
the embedded market and that's where
computers really are. And and as time
goes on, I don't even know what's going
to happen with general purpose
computing. you know seeing what's
happened with AI coming in and you know
it will be great for quantum computing
too for the pulse control part of
quantum computing the pulse you know the
quantum computing does its calculation
so to speak in a way that has a lot to
do with uh with approximate physics but
you have to inject pulses into it to set
that stuff off and that is a very highly
choreogated gap wow
choreographed
task to get everything going at so many
different things all at the same time
precisely timed and not have massive
hardware. BIW fits that like a glove and
uh you know that's that's exciting
because I think that may be like AI is
today that may be a earthshattering
technology
and exciting to think about that. You
know I saw that and I was interested to
see what they were doing instead but I
haven't really kept up with that. I mean
there's only so much you can do when
you're my age and you're playing tennis
three times a week. So,
I kid, but the truth is I don't follow
things as closely as I used. No, you
know, uh, not what do the kids say to
I'm not my grandkids. I'm not glazing
you when I say this. That's what they
say,
>> right?
>> I was stunned by your your BLW video. I
really was because, you know, there were
a few technical details that might have
been nuanced a little bit differently
just to match the history, but they were
unimportant. what was important to say
you really captured what went on there
and that was an amazing thing to see and
you explained it all so beautifully and
I just and you know I I
>> I hang around on YouTube etc. But I had
not run into your stuff now I'm watching
all your videos because they're so
educational and fun. So, you know, I
want to say that was, you know, and just
for your viewers, I immediately wrote
you. Got a Google News alert that your
video on BW existed. And uh I saw it
right after it came out. I immediately
wrote you because I was I was aruck.
Good job you did. and and also, you
know, you you uh
did things that were motivated obviously
by reading Elizabeth, my wife's book,
and uh you did those beautifully and you
gave her such nice credit for it as
well. It was just it was just a
tremendous thing to see and I really
have to tell you how much I admire that.
As I told you,
And that's the interview. Before we
conclude, I want to recommend again the
two books mentioned here. Bob Cowwell's
Pentium Chronicles and Elizabeth
Fischer's Multilow Computer: A Startup
Odyssey. They really are great, and
there are so much more in them, so you
should go check it out. All right,
that's it for tonight. Thanks for
watching. Subscribe to the channel, sign
up for the Patreon, and I'll see you
guys next time.

Apr 25, 2026

Watch Read Summary

What DeleteMe and Incogni aren't telling you

Reject Convenience

Heimler's History

May 01, 2026

Watch Read Summary

PDF

The Multiflow Saga

The Itanium Era

Embedded and Future Applications

Mechanisms & Explanations

Takeaways

Frequently Asked Questions

Why is VLIW considered successful in embedded systems despite the myth of failure?

What caused Multiflow’s business failure despite its technical achievements?

Who is Asianometry on YouTube?

Does this page include the full transcript of the video?

Helpful resources related to this video

Share This Summary

Embed This Summary