← Asianometry
Asianometry
An Interview with Josh Fisher: Inventing VLIW, Multiflow, Itanium, VLIW’s Massive Success
Loading summary
Transcript64 lines
- [00:02]
A
I don't do that many interviews, but when Josh Fisher 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. Fisher is winner of the Eckhard Mauchly 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.
- [00:42]
B
Welcome to asianometry. I'm here with Josh Fisher, emeritus senior fellow at Hewlett Packard and pioneer in vliw. It was. It's a real honor to have you on, Josh, welcome.
- [00:57]
C
Thank you, John. It's an honor to be here. Your video on VLIW stirred up a lot of interest, more than I've seen personally in a long time. For my own work, vliw, of course, has much more interest than ever.
- [01:17]
B
It's actually something I've been really interested about because, you know, came across the. It. It has a reputation. And then when I came went through the literature and the documentation of what you've been, what the work you've been doing, and I thought it was an amazing story. And then when you reached out to me, it was. It was incredible. So, you know, we have a couple things we're talking about, but I want to let you do most of the talking. But how about we start off a little bit with some of the intro material things like what are some of the misconceptions in this about VLIW that we need to put on the table first so people can get that right off the bat.
- [02:01]
C
Right, Great. Good idea. So the biggest misconception is that somehow VLIW was a failed technology, which is a little bit crazy. 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 VLIW units sold. And each of these units, being a particular chunk of silicon, has often has several VLIW 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, but probably something on the order of 12 to 15 billion Bliw 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. Even the units, 5 billion is like 15 times the count of x86s and 12 billion 45 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, that's a whole subject of how people regard embedded computing compared to, compared to general purpose computing. And I would like to get into that maybe a little later. Then there are myths about VLIW being bad because it pushes the complexity into the compiler. It's actually good. And we can talk about that later. Then the company Multiflow. So I started the company with two of my colleagues, started the company that produced the first really practical VLIW computer system. And people like to talk about why it died. And 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 Multiplo died, the business failed. But people then damned VLIW 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 itadium. We'll get into that a little later. And then, you know, there's the broad subject of what matters is the general purpose computer. As I said, you know, embedded kind of puts in terms of processors shipped, kind of puts general purpose computers at the noise level and then hardware versus software. Big prejudice about that. I also, since 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 and I talk about what's happened in the history of the liws. And 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.
- [06:15]
B
It's a good start, I think. Like I remember when I was reading your literature, basically said that you were good at, you ran a good, you ran a good talk. You got a good talk point.
- [06:28]
C
Thank you. Yeah, No, I mean, I've always been a good speaker. And you know, my wife's book, which. My wife's fabulous book about the history of multiflow giving an inside look into startups, which you very kindly gave such a stellar review to in your VLIW 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 came across as the truth, because it was. Yeah. There's my first not very humble statement.
- [07:18]
B
Let's start a little bit with like the history of vliw. Right. You talked a little bit. We talked. I've already talked in the video a lot of that. But like. Yeah, what particular things that kind of, you know, maybe that wasn't mentioned or you want to start out with. You talked a little bit about embedded. I know DSPS is a large part of that history. What did you see from there?
- [07:42]
C
Sure. Dsp. First of all, people think DSP is a chunk of hardware. DSP is an application. 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. What people found was that by issuing lots of individual operations like adds 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 everything ranging to big, not big. Well, big by today's standards. Computers that were attached to things like CAT scanners, GE produced from a company called Floating Point Systems, and high performance actual computers that did scientific computing from 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 was basically hardware designers sitting and laying out the circuit. And the circuit happened to have a fetch execute cycle in it, but they built it as if they were just building hardware, this thing should happen here, this should happen there, this should happen there. When I came along as a graduate student, I was working on a project that had something called horizontal microcode, which was once again controlling the computer using a circuit of the same nature. And, and people hand coded them. And there was a little bit of literature about, hey, can we take the microcode 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 really was misery. It was all tightly interwoven. And the analogy I always use is that if 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, treat like code into this more circuit like thing. And 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 Courant 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, 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 high level 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 floating point systems machine, which was very popular because virtually all the GE CAT 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 vliw and I started building a machine there because 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 or any university. And none of them were. They were all fascinated by it. I mean, part of that's my, I guess, my blarney. But they really did show, I think, genuine interest in it. They sure weren't going to pump millions of dollars into. Was just too risky and not on their P and L to do that sort of thing. And so two of the guys working for me and I started multiflow because we realized we could never do that. We wrote a compiler and the main author of that compiler actually 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. It was a very plastic compiler. That is, you could describe the machine and it would generate code for a machine described that way. 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.
- [15:30]
B
The Bulldog compiler. Right.
- [15:31]
C
The Bulldog compiler was called, as we joked, Bulldog. The Yale Bulldogs. That's what the sports teams, for example, are. And 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 that's a sports competition. Yeah. So we wrote this compiler and we knew we could do it. 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. We marched 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 BIW systems. So we sound like multiflow, and that's the whole long saga. But that's the beginnings of B liw, Right.
- [17:05]
B
And you weren't the. What was kind of at that time, you guys were working on these like super mini computers, right?
- [17:14]
C
Mini supercomputers. Yes, mini supercomputers. There was a category of people often conflated the two. There was a category of computer called 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 supercomputer, but we would be a tiny fraction of the price and give a very large fraction of the performance, which we did.
- [17:49]
B
And you had.
- [17:50]
C
Right.
- [17:51]
B
It was a competitive space. Right. You had Convex and all these different companies that were in that area as well, not to mention Cray and all those big.
- [18:00]
C
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 30. It was certainly well into the 20s of people who were trying to sell into that price performance space. We had the best price performance through most of our, I think, all of our history on the standard measures of that kind of thing.
- [18:39]
B
So you guys competed with all these different companies and the company eventually ended up failing. But like, looking back on it, what precisely you just mentioned earlier, like, there are 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?
- [19:03]
C
So the first thing I have to say is that there's this zaniness and I can't read social media comments about VLIW anymore. There are lots of them. And of course, your wonderful video grabbed a whole bunch more. 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. Multiplo 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 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 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 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, the killer micros had come along. They couldn't compete with us. But what they could do was put an entire fast computer on a single chunk of silicon. You couldn't do that with a VLIW because, two, to get as much parallelism as we got, you needed a heck of a lot of functional units. Our three machines were. They were really one machine that you could expand. Were doing 7, 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, Phillips did it first. Put a meaningful VLIW on a single piece of silicon. And those chips were gonna cost a tiny fraction that we're 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 at a fraction of the performance but far cheaper hardware. So, you know, we were just not in a position to. Let me adjust this camera. I keep staring at you as I should and I'm probably looking sideways a lot. So we really failed because we had no prospect of a next round. And we actually closed the company. And this is an error on my part, though. You know, my part. The CEO, long story well described in my wife's book. And 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, where we were not paying back, vacation pay is a felony on the part of the principals of a company. Whoops. So I got to read in the front page of the New Haven Register whether I would be going to jail or not, because who took vacations? You know, we were a startup. We were working 80 hours a week. So anyway, I wasn't worried about that. The venture capitalists would certainly never let that happen. Right to a very, we were a very notorious startup. I mean it was always, you know, one of these companies to watch full page and business, that business news. Anyway, the major part. Yeah, yeah. Popular Business Week. Thank you, John. The most popular business publication at the time. And you know, our closing was in the Wall Street Journal and you know, it was a big deal and very visible. So I wasn't going to jail. Yeah, I was owed a lot of application pay too, of course.
- [24:07]
B
So like you mentioned that it's not rarely performance, it's not the compiling or the lack of apps. Like what is the kind of. What did the competitor say about you? What was their kind of thing?
- [24:22]
C
I'm sorry, go ahead. No, no. Why is it that we couldn't have a next round of financing? So killer micros were certainly the, the main reason and I would say overwhelmingly dominant reason that we couldn't get people to invest. Investors really caught on to the fact that there was a big transformation coming. Processor chips were going from the very slow things. 486 say that PCs ran on two much more powerful things. And there were these, you know, there were the workstations, sun and Apollo workstations that were kind of demonstrating that you 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 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 system, amazingly engineered system and. 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. Some hundred years ago, people would say, get a hold of yourself, man. Not recognize that 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, 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 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. They had far Faster hardware than we did, which is yet another subject that we should talk about. Even though we beat them on price performance, usually at the customer site, Convex, they could understand it had the same general style of architecture as a Cray, 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.
- [27:27]
B
Emitter, right?
- [27:28]
C
Yeah. Emitter coupled logic is what it stands for. And we use ttl, which was a very, very big generation behind. And people say, in fact, people like to say that one of the 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, it wasn't easy to raise money to build such risky technology. It's remarkable to me that we were able to. And 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, you know, 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, in fact, is one of the mistakes Cytrone, which never did sell anything made, was to build their machine out of fast enough circuits.
- [29:00]
B
So Cydrome being the other VLIW at the time.
- [29:04]
C
Yeah, with Bob Wright, future after that, colleague Bob Rao, an absolutely wonderful person who died too young. 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. And the combination of that 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. When you have buses the size of our buses to push around the data you needed for that much computation simultaneously. 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.
- [30:27]
B
What was some of the problems with marketing?
- [30:30]
C
And so, you know, there was convex in particular, spread a lot of fud, you know, fear, uncertainty and doubt in the marketplace. We always Met them on the marketplace. The one place we didn't, unfortunately, was most of Europe, Germany and most of Asia, which at that time means Japan. We didn't have a presence there at first, which was a horrible mistake and one that I regret not having fought harder to correct. We did have a distributor in Germany, Daimler Benz, who saw, I guess the Businessweek 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. That allowed them also to more deeply discount in competing with us. That was a major error on the company's part. But yes, 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.
- [32:05]
B
What could you have done better to market the technology better?
- [32:08]
C
Well, number one, we should have. We should have 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 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 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. The problem is our CEO who we really had to hire and was great at first for us getting us to be a real computer company. Our CEO came from the very old world of NCR minicomputers and he had a picture of P and L statements and how you make a profit. It was just not appropriate for such a chancey seeming technology and we couldn't convince him. And I should have, you know, I should have. 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 and ship a tech support person with the machine at first because people were frightened. 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 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 because we were competing against vector machines. And 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. Excuse me. It wasn't a perfect marketing slogan. We got away from that. We hired a guy who like so many Multiflow 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 marketeer. He really was. And you know, that was probably a small factor but that was the sort of thing that was a problem. You know, we kind of glued an old fashioned CEO who was terrific for as I say, getting us to have our engineering be on the mark and like a real organized company. None of us had business experience really. 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 Ekdahl was the gentleman's name. He came to our house after he agreed to take this job and the first thing he asked me was when is your weekly staff meeting? I said staff meeting? We're 20 people. If there's something we need to do, we get together and do it. But it's just a whole different outlook on the whole thing.
- [37:03]
B
Anything else you remember about Multiflow before? Maybe we move on to Itanium?
- [37:09]
C
I, I remember endless stuff about Multiplo but I don't know. And also I'm plugging my wife's book a lot here but it really is a fabulous, it's a great book.
- [37:20]
B
It's a really, it's a really good.
- [37:22]
C
Yeah, she did an unbelievable job of giving a view of startups that you just don't see anywhere. You know, the. So there's a lot about multi flow. But 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'd been forceful enough, we could have done a far better job of that. I was exhausted. We were all exhausted. We had worked so hard on this project. Everybody was exhausted. And we closed the company down. When DEC Digital Equipment turned down the deal we wanted to make with them, which would have been a broad marketing and financing deal. And, you know, they turned it down because they would have had their first quarterly loss in their history if they'd done it, is what they told us. But whatever. There was a competing project within Dec. Dec 9000, which was not a success. And eventually the company tanked after that and Compaq bought them. So when we closed, what we should have really done, look, here's Next Computer, if you want a really good example of why 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 Multiflow. And so he started this company called Next with a little E, so N, E, X, D. And so already showing that his marketing was better than ours.
- [39:17]
B
So
- [39:19]
C
he raised $170 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 he 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 as investors. So 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. And 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 VLIW technology, much of which we couldn't own because it was style. Not a thing. It's hard to own style. So we had a lot of little VLIW technology. And that was nice, but hard to sell. It was not nice. 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, as well as the physical copy. We sold the technology rights to use that compiler to a whole lot of people. 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 to compete with our wide instructions, you know, with the amount of parallelism we got. 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 compiler. So that was bad. So you want to get onto Itanium. I don't think I've got some notes, but I don't think there's anything left major to say about Multi Flow. So look, there have been, there have been four attempts to put VLIW into the general purpose marketplace to replace what was on the desktop. And they were Multi Flow and Cytrone Transmeta and Itanium. Transmeta had a VLIW chip, you know, it was after you could build one in a chunk of silicon. And they wanted to use emulation, I guess, maybe some binary translation, but I think largely emulation to emulate an X86. And they failed. But they had a VLIW architecture trying to do that. Amusingly, the technical guy who really started the technical side of the company was a very visible VLIW skeptic for a long time. There have been a few prominent instances of that. So they failed and then Itanium. So I guess I can tell you my Josh Fisher knows everything and everybody else is wrong story about Itanian here. So Multiflow failed in early in 1990. Sideroom had failed 15 months before we did. The other VLIW company started by Bob Rao. The first time we exhibited a multi flow trace was at a supercomputer meeting in Santa Clara in 1987. And Cydrome was there with their hardware. And they had been very much more secretive than we had been. Bob Rao, by the way, once told me. Bob Rau, who was 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 a few booths away at this supercomputer conference, first really big supercomputer conference, I would say. And all the mini 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 had to be big, because it was a VLIW technology that implied a 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. We ran unix, we had our compiler. Our compiler wasn't as slow as people imagine. And we would demonstrate lots of mainstream scientific applications which Sideroom didn't have. And there was another problem I'll get to in a second with Cytrome's hardware. And that was, that was very complex even for a vliw. VWS 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. And they never did sell a unit. And it's too bad. I mean, Bob Rao 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 an amazing person and from South India who got a job at Champaign Urbana. It was the first time he came to the States. And he told me we were later colleagues, he told me that he got off the plane and people said, oh, I'm glad you've come here with such a nice sunny day. And his reaction was sun where? What? So anyway, Bob, 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 released just a couple of days ago. HP Labs had wanted to replace the PA RISC processor with something more powerful and 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 he can help us with this. And Bob, of course wanted it to be a VLIW because he was the other leading proponent of VLIWs. He had a rather narrower modulo scheduling look at VLIWs. But that was a real contribution to the academic effort. And you know, he spearheaded a lot of the design. Fifteen months later, when Multiflow died, I looked for a job. Now, I always expected to be a college professor my whole life, and I looked for academic jobs, but I also looked at a couple of industrial jobs and HP made me an offer. The project sounded fabulous. I loved the Offer I could stay in Boston, move from Connecticut to Boston, but that was fine. Stay on 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 Palo Alto. And you know, Bob was there and I was prospect of working with Bob was an attractive one. And so that was a great job. And it really was. I, you know, the day after I started work, I was building stuff, I was programming, I was doing experiments. And if I'd taken a job as a college professor, my first 18 months would have been raising money, which I was quite tired of at that point because that's 150% of what I did at Multiflow, unfortunately. So I 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 was really unhappy when I saw that architecture. It really violated all of my principles of what a vliw, never mind any computer should look like. It had so much stuff in it. And all that stuff was gonna be very hard to compile for, in my opinion. And 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? It's just not co design. And you talk about John Cock a little with the iteration of Superscalar he was involved with. He was a real proponent of co design, as were we, obviously, at Multiflow. We actually built the compiler first at Yale and then went on to that. And the 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 Worley, another wonderful person who I'll now throw under the bus, they were really very insistent that this is what the architecture would look like. And it was really too late to do anything much about it. And so I simply right away decided I would get involved in more basic research about VLIWs. But I did throw myself. And by then I had started. After a couple of years, I had started HP Labs in Cambridge, Mass. And I got involved in helping us finally get a compiler at HP for this thing. And that was a mess. There were competing teams from Ex Apollo, which HP had bought, and Cupertino where they did their compilers, and people at HPLabs. And some of my guys were. I assigned some of my guys to work with those teams. And it was really not something that fit my desires of what a VLIW would successfully look like and what my desires of what I wanted to spend my time on. And then I moved into embed it myself and the majority of Cambridge labs of HP Labs Cambridge into Embedded. So right away to me. Now, mind you, I have to say before I let myself off the hook here, I went to the first HP intel meeting.
- [52:31]
B
Oh, really?
- [52:32]
C
Yeah. And I was really very excited about the fact that a machine that was for all practical purposes of the LIW 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. Excuse me. However, I felt about the architecture and the ability to compile well for it and the effort involved everything about the architecture. Boy, lucky me. Everybody's going to think I've done this magical thing. And especially after Multiflow's disappointing failure, that was a great thing. You could send me anywhere to talk about how great Itanium was and I would happily do it. But it wasn't how I really felt. You can understand, 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 multiple trace to the Computer Museum and they put it right in their lobby. And the curator would take people on tours and he'd say, here, you see, this was after the Itanian, you see, this is the future of computing right here. That was pretty heady stuff, you know, so. But no, 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 build a VLIW chunk of silicon, which HP wasn't really well equipped to do that we partnered with ST Microelectronics which was well equipped to do that, you know, the Italian French semiconductor outfit. And you know, that effort led to both the ST241 family, which zillions of were sold into, you know, cable box tops and cable set tops and etc. And were used in base stations, cell base stations, a million other places. And then HP used it in our printers, which was my initial goal. So like Itanium. Yeah, 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 Caldwell, who was one of the brilliant multi flow engineers after he got his PhD, read his Pentium Chronicles or any of his oral histories and get a lot More sense of Itanium. Look, you know the whole question of using a VLIW in general purpose, especially the general purpose of the 1990s, the later 1990s, as opposed to when multiflow was in the 1980s, there was a massive application base 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. By the 1990s that just didn't happen. There weren't companies that really succeeded that way. You know, 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. Itanium tried to do that with hardware that made emulating an X86 difficult. 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 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. 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 the Itanium efforts because that wasn't HP anymore. And so I'm really not a person qualified to talk about why Itanium 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 VLIW can ever be in general purpose computing, you can't count it out. But if DraftKings are or that big Hong Kong betting consortium, what is it? Hj? Hong Kong Jockey Club ever wanted to publish a line on it? I bet pretty strongly against BIW ever being in general purpose for as long as we still have general purpose computers, which is another question. So I. Yeah, so go ahead, John. You sent me with something that's always a mistake.
- [58:58]
B
No, it's fun. It's fun. It's also great. I like, you know, I talked a lot, 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 that sort of use cases? Because I think we just jump right into that phrase and I don't think people quite understand it.
- [59:25]
C
Sure, absolutely. 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 user 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, which, you know, as a 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 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. And so it's not really on their table. So one of the reasons people think VLIW has failed is because it failed in the computers that they could see. But the incredibly greater number of computers that we have in Our World in 2026 are VLIW as much as anything. I mean, it's really dominant force now in VLIW. As I say, 12 to 15 billion computers shipped every year is probably a good estimate of that. And lots and lots of companies that we know about have VLIWs. And you probably wouldn't even know having heard about their cells and where their computers are found. You wouldn't know they were VLIWs. You know, the Internet of things right away is just a huge market. Those are, you know, Tensilica, well, Cadence, Tensilica and Siva. You know, those companies ship billions of computers that are VLIWs. They're, you know, 8 and 9 issue is a common number you see around, which is sort of a sweet spot, right. And you know, they do it because the advantages of VLIWs are paramount there. Low power, small, statically predictable behavior. So you know what's going to happen when it happens in advance. The competing architectures that have this dynamic behavior, like superscalars, and the X86 has the same dynamic behavior. They change their timing a lot on the basis of what's going on. And so they're very unpredictable, whereas VLIWs have very predictable timing. And that turns out to be a big benefit along with low fat power, low heat and low amount of silicon. For the parallelism you're getting are huge advantages. And 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 tarred with that. Have you been finding Bluetooth gets more unreliable as time goes on. So smartphones, they're in storage devices. Cars have lots of VLIWs in them. Typically these days. TPUs and MPUs now AI. Google's TPUs, they moved to VLIW from not being VLIW and now they're. TPUs are the huge, massive computers that they train. Their AI, they train Gemini on are all BIWS now. There's just so many markets where the advantages of VLIW make sense and 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 guess that was your question. And where we do so well, I say we have nothing to do with it anymore. But we being the.
- [64:39]
B
What did you work on with the embedded. You mentioned the printers and the ST240,41. That was sort of the space that you worked on ti. You wrote a piece also with TI as well, right? In the ds?
- [64:51]
C
No, I, I didn't really. 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, they. They, you know, they built a vliw and credited their visit to. To us at Yale when they were on that march of manufacturers as being a big part of that. But no, I had no direct relationship with ti. No. All we did in my lab, I say all because it was a huge success as far as HP was concerned. It brought in a bunch of cash, which HP is too big for that bunch of cash to have been meaningful, but it was still a big success. And then 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 bitmap in order to print these little millions of Drops of ink, they eject every second. Sort of unbelievable technology in inkjets and laser printers too. And plotters were in Barcelona. I probably still are. I haven't kept up. But, you know, these big 54 inch printers that architects and designers would use, they needed to do a massive amount of rasterization. And we wanted to build a chip for them to do that because we could bring all the advantages of the LIW to that embedded space. And so I tried to do that with HP. And HP couldn't build the hardware ST did, and ST marketed it as the 241, which I mentioned before was a tremendously significant, 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 Carly Fiorina is the next person I want to throw under the bus. Carly, sorry, recurring theme. Carly 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, but she did some things really, really well. She integrated the purchase of Compaq into hp, which is probably ultimately her undoing. From a cultural point of view, mergers are really tough. And I have my Fisher'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. You can see that with airlines all the time. So Carly did a lot of good things. But she did, in my opinion, tend to hire yes men. And in marketing, she did that. In my opinion, and sorry to slander now an entire class of people, 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 VLIW technology was perfect for that. We were the only ones really equipped to do it. We knew so much about the intricacies of BLIW 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 2,000 maybe, I guess, yeah, 2,000. It was when the convergence was happening. I guess you talk about that in your PDA. Predecessor to smartphones, video, another really good video.
- [69:11]
B
PDAs and cell phones. Yeah, yeah.
- [69:13]
C
So digital convergence was on everybody's mind, and people kind of knew there would be smartphones. Apple didn't invent the smartphone. They just came out with the first really successful one. But lots of PDAs were going in that direction. To me, we had a Massive advantage. We could do all of this media stuff when nobody else could, and we could put it into a phone. And HP already had both the Jornada and iPac, which was a compact smart PDA. They had the hardware framework for it, and it would just be a matter of sticking in VLIWs 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, and I laid out this long list of applications that we could run that are not very different from what a smartphone looks like today. And that was not a piece of brilliance on my part. I think anybody thinking about it would know that 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, gee 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.
- [71:58]
B
What a miss. What a miss. It's unfortunate you talked a little bit about Korent and talking about compilers. What was that about?
- [72:09]
C
So the Courant Institute. So Courant was this brilliant student of Hilbert who 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 probably the best on the planet during his tenure there. 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, because of A gentleman named Jack Schwartz. It was compiler heaven. So Schwartz and Cock, the same John Cocke 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 Ken Kennedy, one of the handful of top researchers in the history of compiling, came out of there. He was Jack student and the atmosphere at Courant was one of the compiling. It was really a lot of what Courant 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 the perspective of somebody building hardware but was fairly expert in compiling. I think that 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. So that's the Quran story. I mentioned that to you
- [74:21]
B
mentioned earlier almost offhandedly, but I didn't. I kind of want to get back to it about general purpose computing. Like you're going to say something about that and I didn't quite follow up on it.
- [74:34]
C
Well, I mean general purpose computing these days needs a new application base. If you have an incompatible architecture that can't do x86, the fact that VLIWs 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 Titanium, 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 customers for it. So not much to say about general purpose except it's certainly far, far less of an easy market for VLIWs. Embedded is far easier because tends to have much less of an application need. You know, there's a handful of things you have to do, mind you, vliws, 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 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 compiler being slow as a disadvantage of vliw and it's not a disadvantage of the liw. It's a disadvantage of having to do a lot of things at once. If anybody could ever build a superscaler 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 VLIW and Superscalar from this point of view is that the hardware eventually has too much to do to make it profitable to 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 an Achilles heel of vliw. It was simply if you want to get that much parallelism to run a single stream program as fast as you can possibly run it, which is what you want to do most of the time, you need that much compiling to find the parallelism. It's as simple as that. So the idea that it sort of threw disadvantages, that it threw the 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
- [78:03]
B
so like, you know, looking back at kind of how VLIW developed and the history of what this technology is, how would you kind of sum it up and what do you reflect on it today? Why is it so controversial in your opinion?
- [78:23]
C
Well, first of all, it's very different. So people generally felt that if this were really practical, somebody would have done it. I think that really was the attitude that people had about it. And then it's, you know, as I said, it's this weird, you know, behind the scenes thing. It's very hard to explain how it works. It's just, and it's very abstract, you know, it's just not, doesn't fit what people, what people expect. And you know, I read, for example, on social media, which I avoid now when it comes to vliw, I read that multiflow failed because it compiled too slowly, or multiflow failed because the hardware was too slow, or these were never factors in why multiflow failed. But I think everybody wants to concentrate on the technology being a different technology. From a business point of view, that's just not what the big factors are. From a business point of view, there were much bigger factors that had little to do with the technology itself. But, you know, the vliw, you know, has proven its worth, that's for sure, in terms of an architecture that gets high performance at low cost and, 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 year by year success in embedded shows that. It's just that the general purpose marketplace is a very different beast because of, if nothing else, application basis needing to be replicated. But today I think if somebody tried to do what Transmeta did, and that's significant, that is put a VLIW on silicon, make it cheap rather than building the kind of circuits we had to build at multiflow 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 they might very well have a good chance of succeeding at it, building cheaper hardware that could go faster than the normal desktops can. Somebody tried to do what Itanium was trying to do, but they'd have to do it right. First of all, I'm not convinced Titanium did it right, as you heard. You know, they'd have to have a lot of money behind them to convince whoever really does need to recompile because emulation and binary translation wasn't fast enough. But I don't know, but reflecting on it, to me in my now old age, VLAW has been successful beyond my wildest dreams ever. I mean, even when I maybe thought it would take over the desktop, 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 as time goes on, I don't even know what's going to happen with general purpose computing. It's seeing what's happened with AI coming in. And it will be great for quantum computing too, for the pulse control part of quantum computing. That's probably not going to be a big market, certainly not in my lifetime, if ever, but it will do.
- [82:58]
B
What do you mean by the pulse thing in quantum.
- [83:01]
C
So quantum computing. So quantum computing is going to be really scary if it really works. And from what I understand, it's entirely reasonable to think it will actually work. But you know, if you wanted to, if you wanted to, let's see, decipher for crypto stuff, cryptographic stuff, if you wanted to decipher a 2048bit key, you wanted to break that key with today's computing, it would take millennia to do it and you could probably do it in a few hours with a quantum computer. I mean it's that for the things that fit that model of computing, it's that dramatic. So the pulse, you know, the quantum computing does its calculation, so to speak, in a way that has a lot to do with approximate physics. But you have to inject pulses into it to set that stuff off. And that is a very highly choreograted gap. Well choreographed task to get everything going. So many different things all at the same time, precisely timed and not have massive hardware needed to do that. BIW fits that like a glove. And you know, that's, that's exciting because I think that may be like AI is today, that may be a earth shattering technology and it's exciting to think about that. But that's probably not a big market.
- [84:52]
B
Do you have any reflection or thoughts about Grok, a company that Nvidia bought for like 20 billion?
- [84:58]
C
No.
- [84:58]
B
Something like that?
- [84:59]
C
No. No reflection, no reflection on that. Nvidia has moved a little bit away from VLIW compared to where they were, but not very much. But 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 to.
- [85:29]
B
Any. Anything else you want to say or before we, before we wrap it up and let you go?
- [85:35]
C
No, you know, I'm not. What do the kids say to me? I'm not my grandkids. I'm not glazing you when I say this. That's what they say. I was stunned by your BLIW video, I really was because, you know, I mean, 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 is that you really captured what went on there and that was an amazing thing to see. And you explained it all so beautifully that I just. And you know, 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. I got a Google News alert that your video on BLIW existed and I saw it right after it came out. I immediately wrote you because I was, I was awestruck at what a good job you did. And also, you know, you did things that were motivated obviously by reading Elizabeth, my wife's book. And you did those beautifully and you gave her such nice credit for it as well. It was just a tremendous thing to see and I really have to tell you how much I admire that. As I told you the day after it came out.
- [87:17]
B
Thank you. I really appreciate it. And you know, I tried very carefully to. To not steal too much of Elizabeth's thunder. So there's actually a lot more in the book that I didn't mention at all. So guys, you need to go buy it because if you want the full thing, you can, you need to go there.
- [87:36]
C
It is a great book.
- [87:39]
B
Thank you so much. I really appreciate you taking the time. It's really special having you on here. It's kind of rare, right? I don't do that many interviews but to have the opportunity to have someone who was actually, I wrote about actually be on the channel, it was really fun. Thank you so much.
- [87:55]
C
Thank you very much, John. I really appreciate this and it's been a pleasure. Thank you.
- [88:00]
A
And that's the interview. Before we conclude, I want to recommend again the two books mentioned here. Bob Colwell's Pentium Chronicles and Elizabeth Fisher's Multi Flow Computer A Startup Odyssey. They really are great and there's so much more in them, so you should go check it out. Alright, that's it for tonight.
- [88:18]
B
Thanks for watching.
- [88:19]
A
Subscribe to the channel, sign up for the Patreon and I'll see you guys next time.