Studly Work: Talking Transmeta with Linus Torvalds
The reason I work for Transmeta is that I think the approach is so studly from a technical viewLinus Torvalds
Wednesday, January 19, 2000 was a long day for Linus. It was Rollout Day for Transmeta: the day the company spilled the beans about what it had been doing for last four and a half years. During that time Transmeta kept a Masonic secrecy about its work. By being the one thing Linus and his co-workers couldn't talk about, Transmeta became the one thing everybody had to talk about. This made for great buzz; but it was pretty weird that a movement built on conversation was led by a guy who had to keep silent about his work.
Until yesterday. That's when the weirdness finally stopped.
The first time I saw Linus at the event, he was pushing his way through the crowd, trying to get safely behind the stage. The second time was when I had sneaked out to get something from my car in the parking lot behind the building. Linus was running through the rain, threading his way between giant television trucks and portable satellite uplink installations, no doubt circumventing the throng inside. The third time was when he came on stage long enough to get his ass kicked at Quake by one of the game's own developers. (Couldn't they find a fairer way to demonstrate Transmeta's equal support of Linux and Windows?)
When I finally got to sit down with Linus in a room upstairs, I expected him to be at a point of maximum stress, final relief, or both. But he just seemed happy to have the thing over with (mine was his last obligation for the day). So it was a relaxed and upbeat conversation.
As background, here are direct links to Transmeta's subject pages (unfortunately, all of the more technical stuff is in .pdf form):
- Doc Searls
Doc: How are you doing?
Linus: Well, I'm so used to doing this kind of thing for Linux. It's much more stressful to do it for the company.
Doc: Because you're a company guy now.
Linus: Well, it's also that I've never done this before.
Doc: Well everybody did a very good job. And I was just talking with Linley Gwennap (one of the leading microprocessor analysts), who was very positive about the whole thing.
Linus: Oh, so Linley is positive? He was one of the ones we knew would be here, and we didn't know how he would react.
Doc: I asked him if Transmeta had in fact achieved the ideals of RISC, and he said yes.
Linus: It's Java.
Doc: It's Java?
Linus: It's Java. Exactly. I mean, it's much harder than Java, because Java was designed for being translated. And the x86 instruction set was definitely not designed for being translated.
Doc: And now it is, in a way, because of what you guys have done with it.
Linus: But you can tell it wasn't designed that way. I was surprised that nobody yet has asked the question, "Why not self-modifying code?" If you design a language for being translated, you cannot do self-modifying code. You just don't allow that trick. But with x86, you have to allow self-modifying code, because it's a fact of life. So it is much harder to translate when you know that the code might change from under you.
Doc: How much energy at Transmeta went into software versus hardware? One person I talked to thought more energy might have gone into software.
Linus: I think it's partly true for the last half year or so. When I came on board, there were about 60 people, and about 5 people were involved with software. Or maybe it was under 10 people. A lot of people came from Sun and SPARC, so a lot of the initial work was in hardware, and there was a lot of speculation about what the software would do. People were optimistic, but you have to be optimistic because otherwise you'd never start. But software is now clearly one of the main issues.
Linus: One of the hard parts is just bootstrapping things. When you don't have the software, you don't really know the problems. You don't know enough really to design the hardware yet. So that's why we had this internal Silicon Spin, and we learned a lot from just being able to run for the first time, at a reasonable speed, major applications. Before that happened, you could simulate, but at such a glacial speed that you completely lacked the feeling for how fast it was.
Doc: What is "Mobile Linux," and how does it differ from every other kind of Linux?
Linus: It's easier to say what it is not. It's not a Red Hat. It's not a distribution. It's not a special kernel. It's really more of a term we have for the people we support. It gives them a sense of what we give them to play with.
Doc: Which is?
Linus: It's the standard 2.3 kernel with some power management stuff done on it, but anybody can see what that is. There is the compressed file system that I made part of the standard kernel not long ago. And that's really the question of ... you have a very limited amount of ROM. You want to fit Netscape in there, too. And you want to page things in from the ROM. You obviously want to compress it. That's number one. But how do you compress it so you can still do random seeks and paging in things? Those are the kinds of questions I spent a fair amont of time thinking about. What's the good way of doing this? What fits in and works well? These are not fundamental design shifts.
Doc: I was impressed at how it worked in the prototypes I saw in the demo room.
Linus: Yes. We have added pieces like the virtual keyboard.
Doc: Is this a Linux thing--this touch-sensitive virtual keyboard that slides out the side of the screen when you want to type?
Linus: It's an X application that takes Graffiti and turns it into X events. So you can feed characters to other applications. It's kinda cool. But it's not rocket science. It's something that Linux didn't have before, and that we wanted to be able to offer any customer coming to Transmeta saying "We hear you have this x86 embedded low power device, and we'd like to do one of these Web slates." There are a ton of people who want to do these Web slates. And they all want to use Linux, because they can't fit Windows in there.
Doc: And they've been burned by Windows CE.
Linus: Yeah. And then at the same time they all have the same questions. So these additional features are ways to say, "Okay, if this is what you want, here is what we have done to get you started."
Doc: The future of computing is clearly increasingly mobile. You've been talking about this for quite a while. What do you see as the future milestones of Linux? What do these developments say about where Linux is going to go?
Linus: Not that much, I think. The fact that I happen to think (in that direction), yes. I mean, it's not just that I work for Transmeta. I think mobility is a good idea.
Doc: The reason you work for Transmeta is that you like ...
Linus: ... The reason I work for Transmeta is that I think the approach is so studly from a technical view. We should have shown technical people real demos of all these tools that show: what's the original x86 code? What did we change it into? Half of what the software group has done is just these tools, for visualization, for figuring out what things we missed, so we can be better at not missing those things. That's just incredibly cool, whether it's mobile or not.
Doc: Are these tools relatively public? Are they exposed at all?
Linus: There is a debugger environment that is exposed, but we don't want to expose the internal stuff. You should think of it as a chip in itself. And there is a lot going on behind the curtains. Basically it's a lot of interesting technology that I don't think anybody has done before. A lot of people have done just in time compilers, and Digital used to do FX!32, which was translating x86 to Alpha. But nobody has done something in this kind of real environment. You didn't have real-time applications with real real-time guarantees, including the whole OS working. So that's what made me want to work with Transmeta in the first place. And then the fact that yes, I think mobile and wireless communications are good and I want more of that. For now it just makes me really happy to be able to say yes, we can do this. I don't have to be ashamed about what Transmeta does. They have all this cool technology.
Doc: I was intrigued by what Dave Ditzel said about how this was something that could not have come out of the chip or the software businesses by themselves; one side wants to throw more transistors at a problem and the other side wants to throw more code and that everybody came from one side or the other.
Linus: Nobody really seriously considered doing this. Even SoftPC. And this is kind of what SoftPC does. It's a lot of the same thing. But at the same time SoftPC does not track with the low level hardware. And it has nothing to do with what Transmeta does. Even SoftPC never even tried to go head-to-head on real CPU performance. Everybody just thought that it can't be done. What Transmeta says is it can be done, but you need special hardware. And you need hardware that is designed for doing this kind of thing.
Doc: It seems to me that this does change the game. Or creates a new game.
Linus: I hope it's true. And that the market will be quick to react to it. There is always a problem when you have a first generation product, and you are comparing this first generation product against the fifteenth generation of your competitor's product. So yeah, we think we're there, but... (laughing)
Doc: I did a bunch of work with Hitachi a few years ago, helping roll out their H8 microcontrollers. I learned then that the company didn't like to make a microprocessor or microcontroller unless it was a "10 - 10 - 10," which was: over ten million units, under ten dollars, over 10 MIPS. Or something like that. I forget exactly what each stood for, but the idea was to start in fifth gear. There was no ramping up in the marketplace. You had to be assured that it would sell to one or two giant customers (including yourself), which guaranteed your volume of umpty-zillion units. Also, everything that was good came out of the central laboratory, which had farms of computer scientists and engineers, working almost at the molecular level to churn out fresh ideas and patents. This was the model for chip development behind consumer electronics. And these are still the guys who make portable units. I'm also not sure it is much different for Nokia, Ericsson, Philips and the European manufacturers. What you're doing here is very different. I'm wondering if there is any concern at Transmeta about the kind of cultures and markets you are dealing with here, coming from the outside.
Linus: One of the things we noticed is that it is clear that American companies don't worry much about bulk. They sell these big, bulky PCs with 14 inch LCDs. And they sell that as a feature: it's got a big manly screen. And they are not too convinced by the power advantage, because for them the system is so large ... who cares when the CPU takes only 20% of the system's power? On their machines, the CPU is a low percentage of the whole system's power consumption. The Japanese manufacturers have been much more open. It also helps us that, on the PC side, they're using Intel. Bend over! (laughter)
Doc: They've been conditioned already.
Linus: So, in some sense, I don't think it's going to be an issue. And, in any case, we're not going into the Super H market.
Doc: What else excites you?
Linus: One thing that makes me excited is that we have this LongRun thing, and it's great.
Doc: It was a great demo - about how the chip adjusts to application behavior.
Linus: The reason you saw power consumption go up at the beginning of that demo is that it needs more power to do the translating up front, but then it's easier, and the consumption goes down. So it's a really good demo. But there also are all of these other areas where we can do something else with software. Especially on the Windows side, if somebody wants to create a really cheap power Windows device and get rid of all the legacy hardware. Let's face it: Windows doesn't work unless you have all that hardware. But we can simulate a lot of that hardware. So there are all these areas where we can use software to do the job.
Doc: Maybe that's a gift to Windows, in a way.
Linus: Strange. We'll see.
Doc: You know, my expectation coming in today was that the rollout would be 90% Linux and 10% something else. Instead it seemed more Windows than Linux. But that makes sense because you have these two classes of chips, and the more high performance chip, with the Level 2 cache and all that, is aimed at the Windows market.
Linus: Looking at the Windows side brings up the issue of soft modems, which do not have Linux drivers. One of the things we've toyed around with is the idea of having the modem driver done by the CPU. So the CPU just dusts the soft modem. And it looks like a normal serial port. Again, it's the same thing: we simulate hardware in software.
Doc: So you're treating certain hardware itself as a bottleneck.
Linus: You always want to eliminate some parts. But look at all the trade-offs we've been able to do on the x86 instruction side. How much of that do we do in hardware and how much in software? We can do the same kinds of things on the system side. We don't do that yet.
Doc: The old chip answer used to be VLSI. We'd just integrate everything we could onto the chip.
Linus: Integration is still a good idea. Because it drives down power, assuming you use all the integrated parts, you don't have to drive electricity between chips. In all of this, the most interesting stuff is what we haven't done. We've been in this panic mode to get the basic instruction set working, without worring about the future too much.
Doc: I'm looking forward over the coming months to seeing how certain things start to resolve: to see how much interest is in your work and not just you, how much interest is in Transmeta and not just the mystery around the company, what the design-ins start to look like and what customers start to show up.
Linus: What I'd really like to have is that little unit we have as a mock-up. (See "Going Mobile." It's the unit in the first graphic.)
Doc: The little pad?
Linus: Yeah, that little one with the pieces.
Doc: With all the pieces that fit around the edge, the game controllers and GPS unit and camera and so forth?
Doc: And they all attach by USB conections? That's the best use of USB I've seen yet.
Linus: Right. And that's do-able right now, from a technology point of view. It's just not economic.
Doc: For the right customer, maybe.
Linus: That screen--there really is an 800 x 600 screen with that form factor, that's really that small --is very expensive. And just getting everything to fit into that size is really hard. They measured with micrometers just to say "yes: we can do this. It's physically possible."
Doc: What's the noun for that thing?
Linus: A work pad.
Doc: And the other one is what, a slate?
Linus: They're the same thing. It's just that the big ugly ones are easily designed. They're full of air. And that's probably what the first generation will look like, just because the first generation won't have all the refinements. We'll need to learn to pack things tighter with our new chip. There's a learning curve. The first versions won't have the optimal packing. Next time, they'll move one chip ninety degrees and find a bit more room. But the small form factor, that's the real challenge. They're hard to do. The big Web slate is the only thing we can demo that works. But it is not something that is going to make a market yet. It's too big to take to the toilet with you. But the small ones are so much more useful.
Doc: You may know the answer to this last question. Nobody else seems to know. It's a hardware question. Do these new chips put out less RF? One of the things I would love to see in one of these little computing devices is a radio: one that picks up regular broadcast signals. The problem in the past with integrating these things is that the computing chips throw off too much RF.
Linus: I really don't know. It's a hard problem to solve. We've seen the heartbeat of the low power modes show up at all these frequencies that depend on what you are doing. It's one reason the power supply is such a critical part of the system. You have to feed a fairly consistent power level, even when it's going from, like, 10 milliwatts to 2 watts, very rapidly. There might easily be RF signals coming out from just those, regardless of what the CPU does.
Doc: In my office I can hear the computers sing over the AM radio, as they move from program to program, or as they spin up the hard drive.
Linus: Hmm. I really don't know.
Doc: Another interesting problem to solve.
Doc Searls is Senior Editor of Linux Journal
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Nice article, thanks for the
7 hours 39 min ago
- I once had a better way I
13 hours 25 min ago
- Not only you I too assumed
13 hours 42 min ago
- another very interesting
15 hours 35 min ago
- Reply to comment | Linux Journal
17 hours 29 min ago
- Reply to comment | Linux Journal
1 day 23 min ago
- Reply to comment | Linux Journal
1 day 39 min ago
- Favorite (and easily brute-forced) pw's
1 day 2 hours ago
- Have you tried Boxen? It's a
1 day 8 hours ago
- seo services in india
1 day 12 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?