Inside Transmeta 77
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."
Even trickier than we thought (Score:3)
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!
Crusoe has substantial merits. (Score:3)
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.
Re:Even trickier than we thought (Score:1)
The Pentium Pro hade serious performerance troubles running 16-bit code, and thus performed very poorly with Windows95 (but performed just fine with everything else). But the market decided that the lacking support for Windows 95 was unacceptable and the Pentium Pro sales were a lot under the by Intel expected sales figures. It never made it to much else than servers and high-end workstations. Granted, all chips are very pricey when new and are often found in servers and workstations at first, but then comes the time when the sales of the chip increase and the price drop and the chip appears in consumer-priced systems, but the Pentium Pro never made it that far.
The original Pentium series continued to sell very well, and later got the MMX extensions. After that, the work began with the Pentium II, basically with a modified Pentium Pro core (for better 16-bit performerance) and the MMX extensions.
Didn't Transmeta learn from the Pentium Pro disaster? It's hard to think that they didn't know about it. Anybody at that time who claimed to be even mildly interested in computer hardware and read reviews knew that the Pentium Pro was a no-no in a system intended to run Windows 95, due to it's lame 16-bit performerance.
But then again, the article states that most key people on Transmeta were senior hardware engineers from Sun and other non-Intel companies, so maybe it's not strange after all that they didn't ever hear about the problems with a specific wintel combo.
is it even faster "native"? (Score:3)
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.
Re:How does Code Morphing software integrate? (Score:1)
Transmeta Laptops? (Score:1)
Re:shameless plug (skip if trigger-happy) (Score:1)
Now tell me how you're going to get an undergraduate average skilled CS student living in Switzerland into this place... as a janitor?
(just joking, really, but I'd kill someone or sell my vital organs to work there
Re:Laughing all the way to the bank (Score:1)
But not what they intended (Score:2)
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.
Re:is it even faster "native"? (Score:1)
The answer to your question is "maybe", but I sincerely doubt it.
Crusoe, as the article mentions, uses VLIW. VLIW normally depends on the compiler ordering instructions in the most effective manner, and taking care of issuing them to the most appropriate pipeline. This takes a lot of complexity out of your chip. You get the advantages of super-scalar design without all of that multi-issue hardware that bloats up your processor.
The downside is that your VLIWs are hardcoded for a specific processor design. The Crusoe has four pipelines, each of them specialised for certain functions. If, in a future version of the Crusoe, they decide to change the number and/or type of these pipelines, the optimal structure of these VLIWs will be completely different.
Now, as I said, normally making the VLIWs (or "molecules" as TransMeta calls them) depends on the compiler. This means that every time you change the internals of the processor implementation, you need to completely re-design your compiler as well - not really possible. But in Crusoe, it's the Code Morphing software's job. And since this comes part & parcel with the CPU itself, you'll always get super-scalar optimization that works with your CPU.
Of course, this brings us to another question. If Crusoe can emulate x86, can't it emulate other instruction sets? Of course it can. But I'm not talking about Sparc, Alpha or MIPS here.
Imagine this scenario:
As someone else mentioned here, let's say you put, say, 8 Crusoes on a motherboard and have the Code Morphing software handle part of the MP. And let's assume that these processors initially act as CPUs in SMP mode. And now you start Quake, and you want some polygon-pushing power. What if the Code Morphing software picks this up, and automatically switches the ISAs of a couple of your processors to GPU mode. Bingo, you've got 3D acceleration WITHOUT buying an expansion card, WITHOUT going through the system bus, and WITHOUT investing into a big bunch of computation power that sits idle 99.9% of the time.
Need a DSP to do sound processing? An MPEG decoder chip to play DVDs? Just switch one or more of your processors into that mode. Need massive computation power for mathematical calculations? Switch them all back to x86 mode.
All this can be done by the Code Morphing software. Granted, maybe you'd like to have different kinds of processors (i.e. some of them might have more FP pipelines) to make this more efficient, but it's all transparent to the software.
I think this could be the killer feature that brings Crusoe out of the mobile market and into the desktop/workstation/server market.
Re:is it even faster "native"? (Score:2)
Firstly, Transmeta do not and have said that they will not publish the 'native' intruction set for the VLIW architecture(s). The only way I can see anyone getting around this is by partnering with them to create a run-time compiler for a different instruction set under NDA. It probably counts are core intellectual property. The two existing processors have different architectures anyway, so you instantly lose compatiblity not only with the x86 but also within the Crusoe series.
Secondly, VLIW processors like Crusoe and (quietly) Merced rely on the compiler doing their instruction scheduling. You therefore won't (unless you have a compiler for a brain) be able to write native assember, and will have a huge job cut out for you writing a C compiler. You may run into problems being able to optimise as well as Crusoe's code morpher even with teh best C compiler in the world, as you don't have as much information as it does since its operating at runtime.
Lastly, the instruction set is optimised for emulation, possibly even specifically for x86 emulation. Not only is its own behaviour going to be odd (they've clearly developed the HW and SW components of the CPU to work toghether, so you've effectively only got half of a processor), but important elements of normal CPU behaviour will be missing. For instance, exceptions will be strange to work with the commit/rollback mechanism, and as someone else has said, important hardware features like the MMU and some 'core' peripherals will be missing, since they're implemented in the processor firmware.
In short - forget it.
Re:They DON'T WANT a native os (Score:2)
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).
Re:How does Code Morphing software integrate? (Score:1)
Code morphing is more efficient than running x86 code on a Pentium. The purpose isn't to make emulators run better, it's there to eliminate problems of legacy in instruction sets, etc. by adding an extra abstraction layer between the execution and the software. I guess you could flash the code morphing engine's internal RAM or whatever, to make code for different architectures run without program-level emulation, but that's not the main point.
Ramble on!
mfspr r3, pc / lvxl v0, 0, r3 / li r0, 16 / stvxl v0, r3, r0
NT (Score:1)
Re:There is no hidden source code in this message (Score:2)
--
No more e-mail address game - see my user info. Time for revenge.
Re:Laughing all the way to the bank (Score:1)
I can live with coprocessors, as long as it doesn't get too outa hand. I highly recommend the 80387. Now that there is one kick butt FPU buddy.
Things that make me hunger for this pie... (Score:3)
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.
Re:Laughing all the way to the bank (Score:1)
-Upgradebility for hardware is now a software option.
-Backwardcompatability is now a sofrware option.
-Kernel/Windows hacking is now a software option
-It would help for SMP, because you can now have several different processors behave the same.
You just need to start writing the software for it...
Re:Laughing all the way to the bank (Score:1)
Is there a place that sells 387s? I need a 387 and three 387SXes for my various old PCs.
Re:is it even faster "native"? (Score:3)
Before reading this article I thought pretty much the same reagardless how nicely and efficent codemorphing is, it causes overhead and slows execution down. The fact that Crusoe still (seems) to keep up with real natice implementations of the instruction set hints a a very high potential for native applications. So far so good.
But
As I read it (please correct me if I'm wrong) the crusoe does not have a MMU at last not a fully functional. So some part of that is loaded off to the Software layer as well, which makes sense since the morphing software does not need an MMU and we need to filter memory access anyway (for those virtual devices). There are other things as well. Does the Crusoe have a privilege system? I doubt it, because it's not needed. These things can be handled solely in software.
The engenieers at transmeta took quite a lot of shortcuts when designing this CPU and as a result it's quite possible that an OS implementation on the bare Transmeta Instruction set would not be possible without seriously compromising the OS.
Plus I could imagine that Crusoe would be a real pain to program. But if I'd be in a position to know that the only pain would probably result from all the glue I put on my chair
Ciao, Peter
Lots of smart people (Score:1)
Re:is it even faster "native"? (Score:1)
Since they plan on changing the VLIW engine in the future and all, they won't ever tell people to release binaries specifically for that level of the processor. I imagine they'd get much better performance w/ an instruction set designed to be easily code-morphable. But, such a set would be a commitment, and therefore generate a legacy. And to make it good would take a lot of engineers. Engineers cost money, and they aren't really selling anything yet. They don't even have a real direction to their company - they haven't commited to competing with Intel/IBM, and for good reason.
Wait for them to become a big company. Then they'll assign the needed engineers to the job and we'll see the Transmeta ISA.
Ramble on!
mfspr r3, pc / lvxl v0, 0, r3 / li r0, 16 / stvxl v0, r3, r0
Re:There is no hidden source code in this message (Score:1)
Re:is it even faster "native"? (Score:1)
Less painful than x86. These ppl know ISAs. I'd like to see what it can do w/ a reasonable architecture, like PPC. Mebbe the performance gains would be smaller, since there's less to optimize, but it would be more parallel...
Anyway, seeing what it can do w/ newer architectures will probably give a hint at what "native" ISAs will give.
And how does less morphing affect power requirements?
Ramble on!
mfspr r3, pc / lvxl v0, 0, r3 / li r0, 16 / stvxl v0, r3, r0
They DON'T WANT a native os (Score:1)
That's exactly the point, they don't want a native OS. They want to be able to change instructions in the chip (or the chip itself) without breaking existing programs. They could make a new chip, with completely different instruction sets and as long as you have the firmware for that chip, the software will run.
Why do you think Intel are still using x86 instructions? Because they have to. If they change something, they will break every program out there. All they can do is raise clock speed or add new instructions, and if you use the new instructions the program won't run in previous processors. Transmeta won't have this problem.
I want one.
Re:I don't blame you for posting that as AC (Score:1)
Ramble on!
mfspr r3, pc / lvxl v0, 0, r3 / li r0, 16 / stvxl v0, r3, r0
Re:I don't blame you for posting that as AC (Score:1)
Re:I don't blame you for posting that as AC (Score:1)
Ramble on!
mfspr r3, pc / lvxl v0, 0, r3 / li r0, 16 / stvxl v0, r3, r0
Re:Code morphing and interpreted languages? (Score:1)
1 Watt Pentium III announced (Score:1)
And that is apparently what Intel is doing:
[Paul Otellini, co-executive vice president at the Intel Architecture Group, in Santa Clara, Calif.] reviewed Intel's ongoing investments in mobile processors, including a demonstration of a 500MHz Mobile Pentium III that operates at less than 1 watt of power, which Intel expects to ramp to 1GHz in the near future. Intel hopes the chip will be ready this summer to enable new, smaller form factors in full-featured mobile computing.
InfoWorld, May 1, 2000 v22 i18 p5
Intel eyes Internet as next frontier to cross. (Company Business and Marketing) Dan Briody.
Web version: Friday, Apr. 28, 2000 [infoworld.com]
Abstracting the hardware (Score:2)
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?
Re:is it even faster "native"? (Score:1)
I don't know about privilege being even in the software (I'm assuming so, but...) but nevertheless, the point is that even if there are not parts in the chip itself and rather are in the software, it does not make ANY difference to the applications and OS because it will still DO those things, just in the software.
And they did not take out most parts of the chip because they wanted to make shortcuts, but rather to streamline the processer itself and let software do the jobs where it was efficient to do that in software.
IMHO that is.
Speaking of which... (Score:1)
Awesome Article (Score:1)
Re:About the win32 part in it (Score:1)
)O(
the Gods have a sense of humour,
The funniest quote . . (Score:1)
LOL!
true compatibility, right down to the native faults in the binaries.
___
About the win32 part in it (Score:1)
There is no hidden source code in this message (Score:1)
Re:The Truth About Linus (Score:1)
A few comments... (Score:2)
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?
You forgot... (Score:1)
If your looking for stuff with Linus on it.. (Score:1)
I have a print copy of the article, and nowhere did they mention Linus torvolds. But, they did have a brief (very brief) mention of Linux.
Mostly, the print article discusses how the company was formed, how the technology came about with some interesting pieces of information on the actual development of the Crusoe, and talks about the trials and turbulations of the above.
I would have liked to see how Linux->Crusoe was going to play a role in Transmeta's future, but considering they would like to cater to all environments (after all, they should be able to morph many/all instruction sets?) giving Linux all their attention/press would take away from that marketing future.
Nonetheless, it's a good article. I have not read the electronic version, so sorry if the E-version has some differnces from the print.
Re:Native Transmeta (Score:1)
But what else can they make it do? Do they have other code morphing technologies that we can download to this puppy and *poof*(tm) it's a Power PC? Or an Alpha?
If it's possible to emulate an x86 in software, what about other platforms?
Having this kind of portable longevity with the ability to be other machines would be tres cool! It would mean not having to buy an x86 laptop, an iBook and a Palm. Just initialize it with the proper interpreter code, and voila! The best of all worlds! [pardon the poor Borg reference :-)]
Laughing all the way to the bank (Score:3)
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.
Re:They DON'T WANT a native os (Score:1)
That's exactly the point, they don't want a native OS. They want to be able to change instructions in the chip (or the chip itself) without breaking existing programs. They could make a new chip, with completely different instruction
sets and as long as you have the firmware for that chip, the software will run
Of course I understand why they don't want to have native OS. My point was that a lot of people (including me) were dreaming about a native OS, because most of the most obviuous advantages of code morphing are not all that important if you use open source software that can be recompiled
to completly fit the current architecture.
But if it's true that the Crusoe lacks some of the more fundamental parts of a Mircoprocessor and simluates them in software this is just impossible. At last if you want to have a real OS(TM)
Not that one would need a real *reason* for a project like that, altough its always nice to have an excuse for hoplessly insane projects. Hell, hacking into the morphing code and trying to figure out how to programm that beast native sounds like fun and making something work that way even more.
Ciao, Peter
Re:Native Transmeta (Score:1)
Personaly of course I'd like to see an A68k Emulation to make my Amiga take off and finally have a nice CPU again I can code assembler for
Maybe some part of custom chip emulations could be done in the codmorphing layer too.
But to be realistic there are three things that bar the way to other 'plugins':
It is not very likely that the simulated instruction set has a way to fall back into nativ Transmeta code. This would be a security risk (No MMU?)
Trade secret. They won't just give the information about codemorphing away, thats the very core of their company, so they'd have to assign staff inside transmeta to do a layer for another CPU.
The trouble with the first prototype (16 Bit Code Issue) suggests that there is a lot of horsetrading involved between implementing the morphing layer and designing hardware. They had to change the hardware to make 16 Bit fast and it is reasonable to expect similar difficulties when moving to other architectures.
Ciao, Peter
Re:Yet another pie in the sky company (Score:1)
I think you're wrong about this, mate. The folks at Transmeta are doing something that not many other companies have considered, and they've ended up with quite an innovative product. Whether that product can be implemented and marketed well enough is yet to be seen, but I beleive it can.
I'm not going to repeat what other Slashdotters have already said about power consumption/mobile computing benefits, but I see something in this product that noone else has mentioned: The chip's code morphing technology could be used as an interpreter for the robust Sun Microsoft Java 2(tm) [sun.com] platform. I believe that there are already ongoing projects for hardware Java interpretation, but Transmeta is in a unique position in that the Crusoe chip could use its code morphing ability to run classic applications and systems in addition to the Java 2(tm) platform, and of course, as others have mentioned, when you throw mobile computing and embedded computing into the mix, Transmeta could become a leading company in embedded systems as well.
I believe that mixing great technologies like Java(tm) and the Transmeta Crusoe(tm) could ultimately lead to a new era of computing, and could in fact take the mainstream market into directions that were previously though impossible. No, this is certainly not a pie in the sky company. This has the potential to be ground breaking technology.Charles Balthazar Rotherwood,
- Sun Certified Programmer for the Java Platform
- Sun Certified System Administrator for Solaris
shameless plug (skip if trigger-happy) (Score:1)
End of shameless plug. Flame away...
Want to work at Transmeta? MicronPC? Hedgefund.net? AT&T?
Re:is it even faster "native"? (Score:2)
written microcode for a VAX, and I'm guessing the issues are
similar, (if more subtle, with caching and shadow registers, and the
sheer complexity of the source architecture). Microcoding feels much
lower level than assembler: you really need to have a grasp of the
underlying architecture to make it work, and the coding tricks tend to
have the same flair as circuit layout: thinking about what data has
got how far in its execution path, and trying to figure out how to
divide up a task to make best use of the available `blocks' of
hardware.
My feeling is that code morphing is the the missing key to making
VLIW work. VLIW was supposed to simplify processor architecture, but
the designs put forward by Intel have increased complexity, and
reportedly disappointing performance.
How does Code Morphing software integrate? (Score:1)
Re:About the win32 part in it (Score:1)
Re:I don't blame you for posting that as AC (Score:1)
Ok, I actually, read the ieee article, and I am still not excited. If everything works out than I will be as happy as anyone. I will not have to eat my words because I have never said that there is no way that they can make it. All I am saying is they STILL have a large uphill battle and they are still quite far from even turning a profit.
So they claim to be two months or so away from a product. They still don't have one! Will their be yield problems? Will they really run as fast as the expect? Maybe, maybe not.
Let's say they come up with a chip that blows everything away. Sometimes that still doesn't mean they will sell. Everyone knows that even though intel x86 chips aren't as good as AMD everyone still buys intel. Better engineering doesn't mean better profits.
If they are even half as smart as all the hype makes them seem then I am sure that they realize how far away they still are and that this is no easy path.
I don't blame you for posting that as AC (Score:1)
Anyway, I will probably be moderated down and loose some of my Karma. Is it my fault for posting "flamebait" or the fault of people on
Re:More confident about Transmeta (Score:1)
There was the VHS vs BetaMax video thing as a famous example and ofcourse there was the OS/2 1.0 vs Windows 3.0 example. There are many cases when marketing matters and technology doesn't.
Even the Linux IPO's are more based on name-value and marketing than on technology. Why is it that the general public knows RedHat and doesn't know Slackware?
It's Marketing.
Now answer the following simple question:
Is the Intel marketing better or worse than the Transmeta Marketing?
Do not get me wrong, I like new technology, but it does need to sell.
Zaaf
---
---
Faster VM's? (Score:1)
Re:is it even faster "native"? (Score:1)
Transmeta's code-morpher-plus-VLIW-chip design frees the hardware engineers from having to support backward compatibility! They can retool and upgrade their chip design almost at will, and the _only_ application they need to worry about supporting is the code morpher. This gives them unbelievable flexibility to take advantage of the latest processor technology.
If they were to start permitting applications to be developed natively for one of their chips, they would lose this ability.
Chris
Re:More confident about Transmeta (Score:2)
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.
More confident about Transmeta (Score:5)
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!).
Re:If your looking for stuff with Linus on it.. (Score:1)
Employee satisfaction at a start-up co. (Score:1)
I wonder how many other start-up companies have a similar strategy
YS
Crusoe articles? (Score:3)
available on the web. There is this official White [nmsu.edu]
paper (PDF), and I liked this [arstechnica.com]
article by Jon Stokes at at Ars Technica, but apart from that I
have seen very little quality information. This essay is much needed.
Re:Speaking of which... (Score:1)
Although Linux is mentioned in the article, the fact that the originator of Linux is a member of the company was not mentioned.
Re:is it even faster "native"? - correction (Score:1)
This is in error.. there are 30 times more applications than WinCE, and they are far more robust than anything offered on any Wince platform. I was given a PalmIIIx at work and a HP journada 830c
Palm = good. Wince= Abandoned Microsoft Code
Re:If your looking for stuff with Linus on it.. (Score:1)
I thought that was cool, but I also thought it would mention something about Linus's involvement.
Too bad..
=(
Re:About the win32 part in it (Score:1)
Re:Crusoe articles? (Score:2)
Have you looked at Transmeta's own pages [transmeta.com]? They have everything I would think of as "technical" from this article except the bit about being "bug for bug compatable" being the hardest bit (and since the article mangled that by defining it as getting the BSOD at the same place rather then tracking Intel's bugs so software dependent on them don't BSOD/segv I'm not giving any credit!). Oh, and the article also gives slightly more detail on what early Si bugs were worked around in software.
The Transmeta page will show you the code sequence the article used, and explain how it is derived, and how fast it is, along with a few others.
What I will say for the article is it did a good job explaining the nontechnical parts. It was intresting what it took to get the VCs rolling. What the work enviroment is like. How psyced the hardware folks are to get to do a brand new CPU every time.
Good article, worth the read. But not for the tech info.
Re:Crusoe articles? (Score:2)
the white paper `The technology behind the Crusoe processor' which I
cited. The Spectrum article does give a lot of technical insights
that I hadn't seen elsewhere: eg. about modelling off-chip supporting
hardware in software, and specifics about the problems the engineers
faced. Readers will get much more out of the Spectrum article after
they have digested the information in the two links I gave.
Re:is it even faster "native"? (Score:2)
I expect so. Except it is likely to be pretty painful since there may be seeming arbatary restrictions like "ALU1 and ALU2 may not both have even register numbers as targets in the same clock cycle" because that may have made the hardware modestly better in some way, and not made the code morpher (much) harder to write. It also doesn't have a "real" MMU (I havn't found out what it does have, so I'll guess a hardware TLB, and all software table walks, but who knows). Oh, and the two biggest problems of all:
The article even gives a good example of the kind of severe eratta the TM can live with. At 433Mhz-ish the CPU worked fine. At faster speeds it can't execute two particular instructions in the same bundle (it didn't say what they were, so I'll pretend they were "ADD with 32bit immediate; BRANCH ON CARRY to 16bit offset"). That would prevent the shipping of a normal CPU (faster then 433Mhz at least). With the TM the code morpher can be set to avoid issuing those two instructions at the same time if the CPU stepping is known to have that bug, and they can ship a 600Mhz version. The performance loss from having to code "ADD with 32 bit immediate; NOP; BRANCH ON CARRY to 16bit offset; NOP" will be tiny, I would be supprised if it was 3%, esp. since the CM may frequently be able to fill the NOPs with other instructions.
That's not to say all, or many steppings have such bugs, but if they put out new version with a better cache (25% perf boost) and it introduced a bug that could be avoided by taking a 3% hit, they can release. Nobody else can, because they can't be sure all fielded code avoids such bugs! TM can because, and only because there is one and only one application, the Code Morpher.
You may as well assert you could make faster VAX programs if DEC (er, Compaq) opened their Microcode, or the 68020 and Motorola. Your right, you could. But it would be extreamly non-portable, and may severly restrict Transmeta/DEC/Moto from being able to make new CPUs if a signifigant app starts depending on that ability.
Re:Crusoe articles? (Score:1)
D'oh! Sorry, you labeled it as the offical paper, but somehow I missed thet when looking at where you link went (not to TM, but off elsewhere). Sorry.
They say they do it, but the don't really say why (I can guess, and you can guess, but neither of us can know). Maybe I am being too hard on the Spectrum article, but all it gives is hints at why things really happened. Somehow that managed to bitter me on the technical side of the paper.
Yes. Or more from those articles after the spectrum article.
Re:The Truth About Linus (Score:1)
Re:Crusoe articles? (Score:2)
Sorry, kind of confusing. I didn't notice the link I gave was a
mirror site.
Re:is it even faster "native"? - correction (Score:1)
What I meant was, the little suite of apps that comes with the Palm are very nice to use for what they do. I've purchased several and each time I've chosen them over the equivalent WinCE systems available. However, they don't give you many apps, the apps each don't do all that much, unforgivably they aren't integrated with one another at all, and most unforgivably, they have not changed more than a click here or there since the Palm Pro years ago, the first version I used.
WinCE, as sucky as it is, works okay on larger form-factor systems that have a full keyboard, though it cannot be compared to the Palm in that sense. Given that I prefer the Palm, and have chosen to purchase it, I just meant that it would be cool if it used a Transmeta chip and could run WinCE also.
and, to finish the explanation, I mentioned it in the context of writing "native" code for the Transmeta because the bundled Palm apps do so little that it doesn't seem that challenging to rewrite them.
Re:Why don't you read the article? (Score:1)
Re:Laughing all the way to the bank (Score:2)
to do with a Crusoe), but doing so much in software is very exciting.
It makes it much easier to design and upgrade coprocessors like math
and 3d accelerators, and to support extensions to instruction sets in
existing processors. Transmeta seem to be keeping the doors to
software changes to the Crusoe tightly under wraps though...
Re:About the win32 part in it (Score:1)
Look at NT.
Re:The funniest quote . . (Score:1)
Anyone remembers the
Another thing: The Transmeta was not the first Chip that had massive Problems with 16 Bit Software was it? And this was a Problem because of the same Operationg system, too.
Ciao, Peter
Native Transmeta (Score:2)
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