# An Interview with Josh Fisher | Inventing VLIW, Multiflow, Itanium, VLIW's Massive Success

## Метаданные

- **Канал:** Asianometry
- **YouTube:** https://www.youtube.com/watch?v=ZF8ohzWmuzI
- **Дата:** 01.05.2026
- **Длительность:** 1:28:23
- **Просмотры:** 18,207

## Описание

Links:
- Patreon (Support the channel directly!): https://www.patreon.com/Asianometry
- X: https://twitter.com/asianometry
- Newsletter & Podcast (available through Stratechery Plus): https://asianometry.passport.online/
- LinkedIn (feel free to connect): www.linkedin.com/in/jon-y-asianometry

## Содержание

### [0:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI) Segment 1 (00:00 - 05:00)

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 VIW architecture. I consider him a legend. Enjoy the interview. Note for the video, my audio sort of desync 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, emmeritus 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. BLW of course has much more interest than ever. — It's actually something I've been really interested about because um you know I came across the 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 uh it was incredible. So, uh, you know, we have a couple things we'll 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 of the intro material themes, like what are some of the misconceptions in this 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 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 BLW 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 uh exposed. You know even the units five billion is like 15 times the count of x86s and 12 billion you know 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 in embedded. And you know that's a uh 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 about 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 Multifflow. So I started the company with two of my colleagues started the company that uh produced the first really practical uh BLW 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 business failed. I mean, yes, that's why Multilow 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

### [5:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI&t=300s) Segment 2 (05:00 - 10:00)

since you just released a really fascinating video about the history of Itanadanium. 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. Um, 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 the 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. So, I guess that's what I'd like to see out of the way for — not bad. is a good start. I think like I remember when I was uh reading your literature basically said that you were good at uh 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 which my wife's fabulous book about the history of multiflow uh giving an inside look into startups which you very kindly gave such a stellar review to in or LIW video. Um, 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 it was. — Yeah. not a very humble statement. — Let's start a little bit with like the history of VIW, 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 like you talked a little bit about embedded. I know DSPs will is a great part is a large part of that history like what what's your what did you see from there? — Sure. So 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 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, you know, everything ranging to big, not big, well, big by today's standards, computers that were attached to things like CAT scanners that GE 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 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. You know, this thing should happen here, this should happen there, this should happen there. And when I came along as a graduate student

### [10:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI&t=600s) Segment 3 (10:00 - 15:00)

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 really was misery. 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 GE CAT scanners had them. And 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 could compile for it. 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 really did uh show, I think, genuine interest in it, but 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 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 it was

### [15:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI&t=900s) Segment 4 (15:00 - 20:00)

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 right was called as we joked bulldog the 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 in the Alen Harvard. So uh you know 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, they were 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 started Multilow and that's the long saga, but that's the beginnings of BIW, — right? And you weren't the what was kind of at that time you guys were working on these like super mini computers, right? — Super computers. Yes, — mini supercomputers. — There was a category of people often conflated the two. 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. And you had right it was a competitive space right you had convex and you all these different companies that were in that area as well not to mention Cray and all those big big — 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 and so they would do that but yes convex and 30 others I actually had a list I think it was 30 it was certainly in uh 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. — Why? So you know you guys competed with all these different companies and the company eventually ended up you know failing but like looking back on it what precisely you just you mentioned earlier like it 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 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 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. Multilow 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

### [20:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI&t=1200s) Segment 5 (20:00 - 25:00)

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 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. And 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 BIW because to get as much parallelism as we got, you needed a heck of a lot of functional units. You know, we our three machines were there 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 Phillips did it first. put a meaningful VIW on a single piece of silicon. And 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 at a fraction of the performance, but far cheaper hardware. So, you know, 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. Um, and I, this is an error on my part, though, you know, my part, the CEO, long 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. the back salary. I learned that in the state of Connecticut, uh, where we were, um, a, uh, not paying back vacation pay is a felony on the part of the principles of a company. Whoops. — Wow. — 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 were working 80 hours a week. Uh so uh anyway I wasn't worried about that. The venture capitalists would certainly never let that happen. Uh 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 in business uh business news. Um anyway the major pardon. — Yeah. The major — 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 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. — So — crazy story. — Yeah. You mentioned that like it's not rarely performance. It's not the compiling or the lack of apps like what is the kind of what did the competitors say about you? What was their kind of thing? — I'm sorry. So, uh — go ahead. — No, no. We Why was it that we couldn't have a next round of financing? So, Killer Micros were certainly 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

### [25:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI&t=1500s) Segment 6 (25:00 - 30:00)

PCs ran on to 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 ran out of the box and it ran perfectly. I mean, it was a really amazingly educated uh 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. You know, some hundred years ago, people would say, you know, get a hold of yourself, man. You know, not recognize that there 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 site, Convex, they could understand it had the same general style of architecture as a Cray, 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. — The emitter, right? — 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, 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 uh to build such risky technology. It's remarkable to me that we were able to and the um 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 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. Cydrome, which never did sell anything, made was to build their machine out of fast enough uh circuits. So, — Cyrone being the other VIW at the time VW. Yeah. 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. 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. You know, when you have buses the size of our buses to push around the data you needed for that much computation

### [30:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI&t=1800s) Segment 7 (30:00 - 35:00)

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 hundred failures before us. But they did and it was a beautiful machine when they were done. — So problems with marketing — 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. The 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 and 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 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 better? Well, number one, we should have uh 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 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. The 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 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. uh and ship a tech support person with the machine at first because people were frightened. You know, 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 and that some of our guys came up with the slogan no vectors and uh 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.

### [35:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI&t=2100s) Segment 8 (35:00 - 40:00)

So, excuse me. It wasn't a perfect uh 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. uh 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 kind of glued an old-fashioned CEO who was terrific for, 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 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, uh, 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? I said 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 on the whole thing. Anything else you remember about multiflow before maybe we move on to ietanium? — I remember endless stuff about multiflow 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. It's a really really — Thank you, John. Yeah, — she did a unbelievable job of giving a view of startups that you just don't see anywhere. um you know the uh so there's a lot about multiflow uh 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 Deck 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 in their history if they'd done it is what they told us but whatever there was a competing project within deck the deck 9000 which was not a success and eventually the company tanked after 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 Multiflow. And so we started this company called Next with a little E. So N we're on E XD. Um and uh so already showing that his marketing was better than ours. Um so uh you know 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 um they closed down by selling their assets in a sane and patient way. And it was

### [40:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI&t=2400s) Segment 9 (40:00 - 45:00)

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 a thing. Um, — and you it's hard to own style. Uh, but we had a we so we had a lot of little VIW technology and that was nice, but uh 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. 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 to compete with our wide instructions, you know, with the amount of parallelism we got. Um 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 on to Itanium. I don't think I've got some notes but I don't think there's anything left major to say about uh multilow. So look, there have been four attempts to put VIW into the general purpose marketplace uh to replace what was on the desktop and they were multiflowing drone. uh Transmeta, an 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 the guy the technical guy who really started the technical side of the company uh was a VW 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 I tanium. So I guess I can tell you my uh Josh Fischer knows everything and everybody else is wrong uh story about Itanium here. So Multifflow failed in uh early in 1990. Um, Sydrome had failed uh 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. Uh Bob Ralph by the way once told me Bob Ralph 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 had 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 supercomputer conference. It was 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

### [45:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI&t=2700s) Segment 10 (45:00 - 50:00)

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. You know, we ran Unix. We had our compiler. Our compiler wasn't as slow as people imagined. Uh, and we would demonstrate lots of mainstream scientific uh, applications which uh, Cyrum didn't have. And there was another problem, I'll get to in a second, with Cyrum's hardware. Um and that was uh that it was very complex even for a VIW. VIWs 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 drum and they never did sell a unit. And it's too bad. I mean Bob Brow 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 uh at Champagne Urbana. It was the first time he came to the states and he told me uh we were later colleagues. 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 and his reaction was son you know where what so anyway Bob uh they had that machine and they had failed and Bob joined 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. Um, HP Labs had wanted to replace the PA risk 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 uh he can help us with this and Bob of course wanted it to be a VIW because he was the other leading propon opponent of VIWs. He had a rather narrower modular scheduling look at PIWS, but that was a real contribution to the academic effort. And uh you know he spearheaded a lot of the design. 15 months later when Multifflow 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 move 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 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 had taken a job as a college professor my first 18 months would have been raising money you know which I was quite tired of at that point — because that's you know 150% of what I did at Multilow unfortunately excuse me 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 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

### [50:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI&t=3000s) Segment 11 (50:00 - 55:00)

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? " And uh you know, it's just not code design. And then you know you talk about John a little with s with the iteration of supercaler he was involved with he was a real proponent of code design as were we obviously at multilow. We actually built the compiler first at Yale and then went on to that. And the uh 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 Warly, another wonderful person, uh, who I I'll now throw under the bus. Um, 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 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 to work with those teams. And it was really not something that fit my desires of what a VIW would successfully look like and 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 me, I came. 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 — Oh, really? — 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. Excuse me. 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 Itanium was and I would happily do it. Um, but it wasn't how I really felt. You can understand. I mean, 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 multifflow 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 see this was after the itanium you see this is the future of computing right here. So you know that was pretty heady stuff you know so but no it's not how I felt about that architecture and I went into a what was a very successful effort in 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 which was well equipped to do that you know the Italian French semiconductor outfit and uh you know that effort led to both the ST241 family which zillions of were sold into uh you know cable box tops and cable set tops and uh etc. and were used in you know base stations, cell base stations, a

### [55:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI&t=3300s) Segment 12 (55:00 - 60:00)

million other places and then HP used it in our printers which was my initial goal. So — like um — 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 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 and 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 multiflow 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 by the 1990s. You just 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. And so, Itanium 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 the Itanium efforts because that wasn't HP anymore. And so, you know, I'm really not a person qualified to talk about why Itanium ultimately failed, but I do think with the big install 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. Although you can't count it out, but you know if uh if DraftKings or that big Hong Kong betting consortium, what is it? HJ Hong Kong 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. — So — I um — Yeah. So go ahead, John. You sent me something that's always a mistake. — No, it's fine. It's fun. It's also great. I like um you know I talked a you know talked about itanium we talked about multilow 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 uh we just jump right into that phrase and I don't think people quite understand it. — 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 uses 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 uh you know is a concept that's been around for I don't know 25

### [1:00:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI&t=3600s) Segment 13 (60:00 - 65:00)

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 a way that the user doesn't see the computer the user just uses the device. So it's things 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 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 VIW as much as anything. I mean it's really dominant force now in VW as I say 12 to 15 billion computers shipped every year is probably a good estimate of that. And 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 there were VIWs. You know, the 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 VIWs. They're, you know, eight and nine issue is a common number you see around, which is sort of a sweet spot. Um, — right. — And, you know, they do it because the advantages of EIWS 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 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 and so they're very unpredictable whereas bls have very predictable timing and that turns out to be a big benefit along with low fat power, low heat, and uh 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 tred 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 LIWs in them typically these days. Uh, you know, TPUs and MPUs now AI. Google's TPUs, they moved to VIW from not being VIW and now they're TPUs. The TPUs are the huge massive computers that they train their AI, they train Gemini on are all VIWs. Now, um there's just so many markets where the advantages of VIW 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 dollars. So you know that's so that's the embedded world. I guess that was your question and uh and where we do so well. — I say we nothing to do with it anymore but — we being the — what did you work on with the embedded? You mentioned the printers and the ST 241. — That was sort of the space that you worked on. — TI you wrote a piece also with TI as well right in the DS. Oh, I didn't really 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

### [1:05:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI&t=3900s) Segment 14 (65:00 - 70:00)

built their I guess TI6000, if I'm remembering right. Um they you know, they built WLW and credited their visit 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. Um, and then, uh, 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 and inkjets. Um, and laser printers, too. Uh, and plotters were in Barcelona. I 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 and so I tried to do that with HP and uh HP couldn't build the hardware ST did and uh ST marketed it as the 241 which I mentioned before was a tremendously successful product. So 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. Uh Carly, sorry recurring theme. Um, Carly was hired, I don't know if you know this name, but she was hired as the HP CEO to replace L Platt. And there are endless stories I could tell about Carly. Uh, but she uh she did some things really well. She integrated the 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, Carly 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 BIW 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. — PDAs and telephones. Yeah. — Yeah. 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 Jonatada and IPAC uh which was a compact uh smart PDA. Um, they had the hardware framework for it — and it would just be a matter of sticking in BIWs as embedded processors

### [1:10:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI&t=4200s) Segment 15 (70:00 - 75:00)

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 uh 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 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 gee whiz the response I got back was no that's not 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. — Oh, what a miss. It's unfortunate. — You talked a little bit about um Corant and talking about compilers. What was that about? Ah 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 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 was actually tightly integrated with it uh 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 uh I had a pers 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 was there. So that's the Quran story. I guess I'd mentioned that to you — before. — You mentioned earlier almost off-handedly, but I didn't I kind of want to get back to it about general purpose computing. — Yeah. — Like uh you're going to say something about that and I didn't quite follow up on it. — 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 you know the fact that vibws have more compiling for the application writers to do when they want to run on your machine

### [1:15:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI&t=4500s) Segment 16 (75:00 - 80:00)

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 less of an easy market for VIWs. Embedded 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 settop box, but it 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 VIW and it's not a disadvantage of VIW. It's a disadvantage of having to do a lot of things at once. — Yeah. 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 VIW. 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 — so like um you know looking back at kind of how VIW um developed and the history of what this technology is kind of how would you kind of sum it up and what would you what do you reflect on it today? Why is it so controversial in your opinion? — Well uh first of all it's very different. So people generally felt that uh 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, be 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 VIW. I read uh that multilow failed because uh it compiled too slowly or the hardware was too slow or these were never factors in why multilow failed. But I think everybody wants to concentrate on the technology being a different technology from a business point of view. And 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 uh you know the VIW you know has proven its worth that's

### [1:20:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI&t=4800s) Segment 17 (80:00 - 85:00)

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 yearbyear 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 uh bases needing to be replicated. But today, you know, I think if somebody tried to do what Transmeta did and that's significant, that is put a VIW on silicon uh make it cheap rather than building the kind of circuits we had to build at Multiflow 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 as time goes on, I don't even know what's going to happen with general purpose computing. You know, it's 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, but it's probably not going to be a big market certainly not in my lifetime uh if ever. But it will do that. — What do you mean by the pulse thing in quantum — pulse? 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 uh let's see decipher for crypto stuff, cryptographic stuff, if you wanted to decipher a uh 200 240 bit key, you wanted to break that key, it would with today's computing, it would take millennia to do it. And you can probably do it in a few hours with a quantum computer. I mean it's that right for the things that fit that model of computing it's that dramatic. So the pulse you know 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 needed to do that. The LIW fits that like a glove. And uh you know that's exciting because I think that may be like AI is today that may be a earthshattering technology and uh it's exciting to think about that but that's probably not a big market. — Do you have any reflection or thoughts about uh Grock a company that Nvidia bought for like 20 billion? — No — something like that. — No reflection.

### [1:25:00](https://www.youtube.com/watch?v=ZF8ohzWmuzI&t=5100s) Segment 18 (85:00 - 88:00)

— No reflection on that. You know, Nvidia has moved a little bit away from VLW 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. Yeah. Any uh anything else you want to say or before we uh before we wrap it up and let you go? — No. You know, uh I'm not What did the kids say to I'm not my grandkids. I'm not glazing you when I say this. That's what they say. Uh uh I was stunned by your BIW 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 to say. 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 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 BLW existed and uh I saw it right after it came out. I immediately wrote you because I was aruck at what a good job you did. And also, you know, 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 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. Thank you. I really appreciate it. And I, you know, I tried very carefully 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. — It is a great book. — Thank you so much. I really appreciate you taking the time. It's really special having you on here. Um, it's kind of rare, right? uh 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 was really fun. Thank you so much. — Well, thank you very much, John. I really appreciate this and it's been a pleasure. — Thank you. — And that's the interview. Before we conclude, I want to recommend again the two books mentioned here, Bob Colewell'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.

---
*Источник: https://ekstraktznaniy.ru/video/51189*