Slashdot Mirror
Inside Transmeta
Quite a number of people have written about this story - here, ContinuousPark writes: "IEEE's Spectrum magazine has an interesting article with a step-by-step account on Crusoe's design process. It also talks about how they got the venture capital by creating the term 'code morphing,' how they hired their staff and how is it to work there, among other details."
"Apparently Windows95 still had a lot of old 16-bit code in it, whereas Unix (as well as Windows NT) used a flat memory model with pure 32-bit code. Supporting 16-bit code was something that Transmeta had decided to offload into software... The redesign process added about a year to Transmeta's development time."
Transmeta would have been done a year ago, except that Win95 was apparently designed so badly that it took them a whole year to get their technology down to that level. Yet another example of Mr. Gates thwarting the competition!
Unhappy? Kill your television.
There are a few things that you seem to be overlooking, here:
Anyone who feels like dual-booting to Windows on their Crusoe notebook is perfectly free to. They aren't Linux-only. They're emulating the x86 _architecture_, not just a particular operating system.
If you want to play Quake III, use an Athlon or a Pentium III. Power consumption is not an issue for game machines. However, the Crusoe is not _targetted_ at game machines. There is a vast market for extremely low-power, reasonably good chips for PDAs and notebooks, and this chip looks perfectly targetted to that market.
Most PDAs do not use x86 chips at the moment. You could build a PDA around a Crusoe with x86 binary translation and bash Linux into shape for PDA work - or you could write a new code morphing later for ARM and/or Dragonball emulation, and use PalmOS et. al. without modification.
Summary: Crusoe does many things well, and is well-targetted for its niche. You seem to be assessing the chip purely from a desktop standpoint, which leads to questionable conclusions.
Code morphing looks to be a very clever trick, building support for optimizing compilers into the processor architecture for runtime compilation of machine code.
So, let's say it's successful (it isn't guaranteed). Once this architecture (actually, I guess it's a family of architectures from what I've read before) establishes itself, wouldn't code written to run "native" run better? By this I mean, code that does not do the things that are harder or more "heat" expensive to emulate. Aren't they neglecting an opportunity for OEMs to create even zippier devices by pitching it only as an x86 emulator? Using the Palms formerly known as Pilot for the standard, there's not a lot of software there, the apps aren't very rich: a device that did that by default, with WinCE running as an app would be kinda cool.
Intel and AMD can play this game too; it's quite possible to switch parts of their x86-type CPUs off, and they can probably run the clock speeds up and down too. Now that somebody has exploited the low-power high-end x86 niche, we'll probably see the big guys in it too.
The article points out that RISC instruction sets perform better than
i86 instruction sets. And I heard a rumour that they work working on
JVM support (best of luck to them... they've got their work cut out).
Yow. Slashdot's HTML source is horrendous, but I found the message. Clever. :)
--
No more e-mail address game - see my user info. Time for revenge.
Win dain a lotica, en vai tu ri silota
If you would read the article, you would find that Linus is not even mentioned.
As for the product, I'm a believer. Here are some of the things that exite me about the product:
* Variable power consumption depending on the task at hand.
* Code morphing means that they can change the hardware completeley to enhance specialized tasks without recompiling the software.
* Can run binaries for multiple architectures at the same time.
* First really new chip design in some time.
* Dynamic optimization of running code to improve application performance.
The last point has been proved quite well in my mind my Sun's HotSpot technology for Java. I've seen my own code, my own examples greatly increase in speed using HotSpot.
Dynamic compilation con provide great speed increases as it can improve speed of code that you run the most - No matter how much a developer profiles an app ahead of time users always end up using the application at least a little differently than anticipated. It also fits the way I've seen most users (including myself) using computers, where you spend a long time working with a small set of applciations.
The chips may be a little slower now, but especially in the area of portable devices speed may not be your primary concern. I really don't care how many FPS I can get out of UT on a laptop as much as I'd like to run it a week on the same battery.
That's where the hardware improvement flexiblity comes into play. By redesigning software and hardware, they could design to go a lot faster if they want to - or, they could design for a lot lower power consumption than they have even now. One of the critisms of the chip has been that the ARM chips run with even lower power usage, but that may not stay true forever. Remember, it wasn't until the last year of design that they even considered low power consumption an important goal at all! Lower power chips are probably the first goal they have in mind now. for the next chips they produce.
I haven't bought a laptop yet because of the terrible battery usage. A Transmeta laptop would be very appealing to me if it could make battery use last a whole 24 hours, and also provide a good level of performance for Java and Linux applciations (so I could do design work with TogetherJ on a plane or in a hotel room, for instance).
Do you not think there is a HUGE market for laptops (that can also run Windows stuff) with a battery life "only" three times greater than the nearest competitor? Sounds like a pretty level headed plan to me.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The Transmeta design abstracts the hardware from legacy software, which means chips can be redesigned as the future brings new hardware demands. This is good - better than x86 which might have been designed well for 1978 but is a dead weight now. However, Transmeta have patents on this technique so if this chip becomes dominant, Transmeta will have a chip monopoly. I realise that there aren't that many chip companies at the moment because there is a large natural barrier to entry (the cost of a fabrication plant); however, at this moment there is competition between AMD, Intel and to a lesser extent things like ARM and Alpha.
Another way of abstracting the hardware from software is the way the free unixes do it - have a portable kernel and libc and use source compatibility. This only works for open-source software but has the advantage of not needing to rely on another monopoly. If GNOME and K Office get popular, this may provide serious competition with Transmeta's chip. Anyone reckon Linus has a conflict of interest? [Depends what his job at TM actually involves]
The third way is the Java way, with bytecode. The trouble is that the Java language is under Sun's control so this again carries some danger of creating dependence upon a monopoly.
How difficult would it be to have some sort of "portable C bytecode", which could be compiled later into a native executable for a given architecture? I realise this wouldn't work for C programs which assume sizeofint, endianness etc., but lots of the best quality free source code doesn't make such assumptions. If there was such a bytecode format, then good coding practice would be sufficient to create a portable app, and this would include non-free software distributed in the bytecode format. A way of allowing consumers choice of architecture for non free software?
perl -e 'fork||print for split//,"hahahaha"'
Apparently Windows95 still had a lot of old 16-bit code in it...
;)
I didn't understand this part of the article--isn't Microsoft known for it's innovative, leading-edge products? How could their products get to be burdened with legacy code?
Hey, I would think that Transmeta's unique design would make it easy to transition it from being a 32 bit platform to being a 64 bit platform. Does anyone think this is going to allow them to come out with a product that will compete with the IA64?
Respondeo dicendum quod . . .
Venture Capitalists who put money into Transmeta are liking there chops already. It's going to take some major goofups for this baby to do anything but rake in vast piles of money.
Sure it's not the fastest chip out there but it is fast enough for most things. iNTEL will over the next few months have to market it's laptop chips as a way to play Quake on the road. There is a good chance that they will make an offer on Transmeta. There is also a good chance that Transmeta will say no.
Why no ? Because after reading up on how these chips work I have come to realize that this "It's a low power chip for portables" argument is just to get a leg in the door. The way Code Morphing works suggests that it will be possible to gang several chips together and have them perform like a single, very fast CPU. All it takes is modifications to the code morphing software.
Do SMP at that level then again at the OS level and you will have 16 and 32 way machines that scale like 2 way or 4 way boxes even under Linux 2.0 or Windows NT 4.
When ( not if ) Transmeta moves into the high end they will dominate it for a few years just as they will gradually come to dominate the portable market.
--= Isn't it surprising how badly I spell ?
You're exactly right. Successful Marketing is key to sales.
Although I wasn't stressing the marketing aspects in my (badly misspelled) post, for Transmeta to be successful as a company marketing (actually, sales) is key.
But, in this regard I think we've been confident of Transmeta for a long time: what other chip-startup has generated the buzz and excitement and anticipation over a x86 compatible chip (that may or may not be cheaper than Intel's own chips)? Name the current crop of x86 compatible chip manufacturers. "AMD, uh...". Now name the x86 chip manufactures whose every move is reported by even mainstream media with baited breath. Hmmmm....I can only think of one.
That Transmeta has a marketing edge is indisputable. Whether that will translate into sales is.
But I know I'll be rushing out to handle (and buy?) the first products available...
Oh, BTW, VHS vs Beta wasn't a matter of Marketing Prowness. Sony marketed Beta to the hilt. But VHS was an open standard that was good enough for the market's needs and cheap enough to distract the market from the better (and more expensive) Beta. In this regard, Transmeta may be on the right track, too. Why? Because they are targeting the industry standard x86 platform instead of some brand-new proprietary but technically superior and award-winning instruction set (think: Alpha). Transmeta won't even release the VLIW codes for direct manipulation (because they don't want to distract people from thinking their chip is in the x86 market). Of course, Crusoe may not be cheaper, but they are at least going for the largest market segment.
With Hype, Goodwill (they hired Linus), and technological promise on their side, I'm sure Intel, AMD and uh.... the others are worried.
-- @rjamestaylor on Ello
Don't misunderstand, I am a fan of Torvalds.
It's just that Transmeta is not Linus' idea, it's his employer.
The fact that this article details the vision (and results of the working-out of that vision) rather than hyping it's Most Famous Employee(SM), is a Good Thing(TM).
Go Transmeta! (And, go Linus!).
-- @rjamestaylor on Ello
There has been a dearth of good technical analyses of the Crusoe
available on the web. There is this official White
paper (PDF), and I liked this
article by Jon Stokes at at Ars Technica, but apart from that I
have seen very little quality information. This essay is much needed.
Now up until I read that article I always wondered, why Transmeta refused to reveal their code or port an Operation System to the native instruction set of their CPU. There were several quit good reasons given for that but this article came up with another one at last I wasn't aware of:
Nor did it have memoy management in the front end of the machine
Now do I read this correctly? The Transmeta does not have a MMU in the usual sense? No Memory protection and such? I can clearly see why something like that could be left to software, especially if you target more than one intruction set but this would definetly a problem if you ever wanted to build a native OS for Transmeta CPUs.
Ciao, Peter