Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Transmeta

Inside Transmeta 77

Posted by Hemos from the take-a-look-inside dept.
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."
This discussion has been archived. No new comments can be posted.

Inside Transmeta More

Inside Transmeta

Comments Filter:

  • Even trickier than we thought (Score:3)

    by ZetaPotential ( 186121 ) on Monday May 29, 2000 @05:52AM (#1040783)
    "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!

  • Crusoe has substantial merits. (Score:3)

    by Christopher Thomas ( 11717 ) on Monday May 29, 2000 @05:53AM (#1040784)
    But what have they actually got to show for all of their venture capital and demonstrations? Not a lot, just a fair of fancy chips that run at about a quarter of the speed of most chips today. Sure, they use less power, but their performance is a joke, and their oh-so-fancy "code morphing" technology looks a bit overrated since the chips are just running Linux.

    There are a few things that you seem to be overlooking, here:

    • Crusoe chips also run Windows.
      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.
    • Power consumption is very, very important for notebooks and palmtops.
      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.
    • Code morphing gives Transmeta an "in" on Arm and Dragonball territory.
      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.
  • Wasn't this exactly the same thing that nearly made the original Pentium Pro a disaster for Intel?

    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)

    by swinge ( 176850 ) on Monday May 29, 2000 @05:55AM (#1040786)
    Transmeta seems like it must have been a really fun place to work over the past few years. I've been lucky enough to find a few great groups of people to work with, but Transmeta seems to have all the ingredients. I like smart people, I like a large number, and I love it when they bring dinner in! Cool.

    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.

  • I can't see how it should be a problem doing this other than they may not have had it as a design goal so it may not work well with this version. I could highly imagine them taking this into account on the new versions. I was also mentally comparing the Transmeta CPU's w/ the articles they had posted here about a week ago about Linux on IBM's mainframes and how those had virtualization and such built into the design. Having this code morphing layer I'd think that the Transmeta CPU could handle this at least as well if they set their mind to it. This would allow further neat tricks such as booting Windows within Linux at the same speed as if it were booted as just one or the other. I'd like to see them work on this, possibly with the FreeMWare project and VMWare. Of course they probably want to pay the most attention to the x86 instruction set so Java, PowerPC, and others may be long in coming.. this would be a good reason to open the source to all their code morphing software so that we could port other instruction sets over. You'd still need an OS that was aware of the possibility though I'd imagine.. otherwise it'd probably not try running them in the first place.. and you might have to flag your binaries by instruction set in some manor without interferring with the default instruction set being executed w/out user intervention.. hrmmm.
  • Does anyone know if any company is selling (or soon will be) Transmeta powered laptops w/ Linux? I need a portable computer suitable for both work and play and I'd rather throw my money in with those I'd like to support if possible. :)
  • Oh yeah I'd love to work at Transmeta, count me in!

    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 :)
  • I'd rather throw away the lame x86 emulation code which they call code morphing.. it seems to me a trivial interpreter with dumb caching. take the VLIW core, write a real compiler for it, and then you might be heading at something. BTW, I don't think that we'll see 16/32 way machines that soon, because those have to be NUMA, and there's no real OS / PL environment and apps that can take advantage of that. (you couldn't be more pessimistic ;) I'm doin' my Msc. on parallel programming....)
  • The usefulness of what Transmeta has done has little to do with the VLIW/translation architecture. It's the power management stuff that turned out to be useful. Intel and AMD haven't focused on battery powered devices until recently; most of the volume was on the desktop and the demand for fast CPUs in battery-powered devices was limited. This has changed, and Transmeta came along at the right time to exploit it.

    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 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.

  • There's be several problems with trying to write native code for Crusoe series devices. I am astonished none of the follow ups have pointed some of these out.

    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.
  • 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).
  • How would you realistically use code morphing?

    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
  • I'd love to look at NT. But my Timex Sinclair won't run the darn thing.
  • 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.
  • ...but doing so much in software is very exciting. It makes it much easier to design and upgrade coprocessors like math and 3d accelerators...

    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)

    by SuperKendall ( 25149 ) on Monday May 29, 2000 @06:08AM (#1040799)
    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.
  • mod #32 up _MORE_.
    -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...
  • I highly recommend the 80387. Now that there is one kick butt FPU buddy.

    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)

    by dadith ( 119849 ) on Monday May 29, 2000 @06:39AM (#1040802)
    Well I've posted an article aboout that somwhere in this discussion but I think we overlapped a bit ;)

    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
  • My former co-worker's ex-boyfriend's brother works at TransMeta, an incredibly smart fellow. He absolutely loves it there. An amazingly talented and intelligent group of people to be working with. If smart people are your thing, you couldn't be happier at the place. Personalities on the other hand...

  • The way I've been figgerin' it...
    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
  • Cute, but you spelled "typos" wrong.
  • Except it is likely to be pretty painful...

    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
  • 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.

    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.
  • They do have a product, the article (if you read it) says that they've been running prototypes for a few years, and no you haven't been moderated down, tho you should be for making smart-ass comments w/o reading the article first.

    Ramble on!
    mfspr r3, pc / lvxl v0, 0, r3 / li r0, 16 / stvxl v0, r3, r0
  • There is a HUGE difference between a prototype or two and a mass produced reasonably product. And no, I didn't read the article. I am still pissed off at the last time I wrote something not 100% favorable about everyone's favorite company and got my butt moderated down -- and yes I did read the article then. I am going to wait until they actually have a product mass produced before I bother reading much about it. Going through all the millions of rumors about this company is just a waste of time. I hope they do well but until the give me something to be excited about I am not going to get very excited. If they have something insanely great I will be the first in line to buy one.
  • No really, they have a product catalog, and mass production and shipment is scheduled for the next month or 2. IBM is manufacturing them, so that kinda narrows the gap between prototype and shipping :v).

    Ramble on!
    mfspr r3, pc / lvxl v0, 0, r3 / li r0, 16 / stvxl v0, r3, r0
  • the fact is that java code is very similar to C code. the good stuff ( like preventing buffer overflows, automatic unallocation of memory etc ) are worthwhile things to have anyway. if youre writing any kind of a decent server based system - javas the way to go. on a server you can throw CPU and memory at it without any problems..for standalone apps java is not there yet tho. linux also has built in kernel support for java binaries BTW.
  • 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.

    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]

  • 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?

  • Yes it's true that Crusoe does not have MMU built into the chip, but it DOES have it built into the software. And the software is on the chip itself. So, as far as the OS is concerned, MMU IS there.

    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.
  • I hope for once Linus' purpose will be detailed - too many people have lame-ass conspiracy theory schemes.
  • I read it earlier today, and I have to admit they have some really great ideas. Sounds to me they're as good with business practices as they are with processor design. Kudos to them for all they've accomplished and to all they hope to... -PhaseBurn
  • I think Win32 must be one of those fancy recursive acronyms: Win Is Not 32bit.


    )O(
    the Gods have a sense of humour,
  • . .is this one: One of the challenges of creating the Code Morphing software was to make the Crusoe processor, in many cases, bug-compatible with the x86 so that it would generate the so-called Blue Screen of Death at many of the same times an x86 processor would.
    LOL!
    true compatibility, right down to the native faults in the binaries.
    ___
  • I wonder if they were at all surprised that unix ran better than win95 - because unix was pure 32-bit, and windows had 16-bit/32-bit mixed. How can they call it Win32? =P --Sts
  • why was it moderated down? there is no proof that this epic story is based on fiction, insanity or drug abuse. I presume, acting in defense of this aspiring auhor gets me at least a -1 moderation. Though being on the verge of becoming a troll i take this burden. swashbuck
  • 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?
  • to mention that Linus made the cover!!! Ok... the other guys are there to. Bye.
  • Your not going to find it.

    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.

  • Code morphing is an achievement in itself! If they want to keep the native instructions as a trade secret, that's cool.

    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 :-)]

  • 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.

  • 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
  • The possibility of emulating other instructions sets has been discussed before.

    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

  • 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

  • Hey, at least it's not 100% off-topic. Anyway, I just happen to be really excited that Transmeta is one of our clients. Click my sig for details.

    End of shameless plug. Flame away...

    Want to work at Transmeta? MicronPC? Hedgefund.net? AT&T?

  • Well, I don't have any insider knowledge into the Crusoe, but I have
    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.

  • My question is, how would you realistically use code morphing? Let's say you boot up Linux under x86 code morphing software. Would it be possible to add support in Linux for a Java VM layer? i.e. the ability to execute Java programs, and have the Linux kernel load Java Code Morphing Software into the processor, and execute the Java instructions? Could two Code Morphing software machines run concurrently on the same processor? Or would the processor have to somehow switch completely between the X86 and Java code morphing software layers at each context switch? If it could somehow manage execution of multiple architectures (by switching the code morphing software on the fly or having it run concurrently), things could get very interesting. Run PowerPC programs under X86 Linux? Vice versa?
  • Q: How hard is it screw up M$-bashing? A: Pretty easy, if you don't know what you're talking about. It's that much more embarassing if you've muffed a technical fact. "Win32" is an interface, not an implementation. It's actually a family of interfaces that share a common subset of functions. Individual implementations may use 32-bit code, 16-bit code or some combo.
  • I have not yet begun to ramble.

    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.

  • Everyone knows that on /. if you say anything bad about the beloved transmeta you get moderated down faster than Bill Clinton goes after a french fry. The fact is that they have no product yet. Even if their product totally kicks butt (which it probably will) there is a difference between building something that kicks butt and selling it to the brain dead public.

    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 /. for not being able to accept an opinion that is different than there own? What I hate about the moderation system is that if you aren't careful it can lead to censorship (something /. is supposed to against.)
  • You might be more confident about Transmeta because of the technology. But think about it, when was the last time that technology mattered more than marketing when it comes to the big sells.
    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

    ---
    ---
  • Does this mean we will get optimized virtual machines (VM), like the real thing (tm) performance?
  • Yes, we can assume that applications coded for the native Transmeta processor would function better, but to allow that would destroy the single greatest advantage that code morphing provides.

    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

  • You might be more confident about Transmeta because of the technology. But think about it, when was the last time that technology mattered more than marketing when it comes to the big sells.

    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.

  • After reading the article (which everyone does do, right?) I am more confident about Transmeta's technology and future (in the current market dynamics, of course). Why? Because the article does nto mention Linus Torvalds once (except. perhaps, in general reference in the "we hired people straight out of college" section).

    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!).

  • True, the article is about the chip, not Linux. However, as I mentioned in an earlier post, we do get a spiffy picture of him along with the a few other Transmeta members. (Third guy from the right w/ the blue shirt & glasses for all you non 31337s out there.) ;-)
  • One of the more interesting aspects of Transmeta, IMO, is how they managed to keep things under wraps for *5* years. This article mentions Transmeta's hiring strategies and methods for keeping their employees happy and productive. I am thinking of printing out the article, posting it at my workplace and highlighting that paragraph ... ;-)

    I wonder how many other start-up companies have a similar strategy ... any comments?

    YS

  • Crusoe articles? (Score:3)

    by Chalst ( 57653 ) on Monday May 29, 2000 @05:33AM (#1040843) Homepage Journal
    There has been a dearth of good technical analyses of the Crusoe
    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.
  • Interestingly, he made the cover (in a group photo), but not the text of the article.

    Although Linux is mentioned in the article, the fact that the originator of Linux is a member of the company was not mentioned.
  • You mentioned in error that there were fewer palm apps than winCE apps.
    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 .. The palm get's used, the journada sit's in it's cradle unused.

    Palm = good. Wince= Abandoned Microsoft Code

  • Yes, and your right =))

    I thought that was cool, but I also thought it would mention something about Linus's involvement.

    Too bad..

    =(
  • I could not tell from the article, but I suspect that the 16 vs 32 bit has as much to do with typical applications as with the OS: they ran some "typical" workload and found a lot of 16 bit code. The article didn't go into any technical detail about the performance measuremnt, but surely they were trying to figure out whether or not the chip would be competitive running common Windows "laptop" applications: after sll the emphasis (at least in the end) is on low power and mobile devices: they almost certainly weren't running Windows NT and "server applications" to see if their performance was accaptable.
  • There has been a dearth of good technical analyses of the Crusoe available on the web

    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.

  • The only article at the Transmeta site I found really illuminating was
    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.
  • 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?

    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:

    • Transmeta has two diffrent CPU products the TM3120, and the TM5400. The two CPUs have diffrent (internal) instruction sets. The future products are likely to as well, with some of them being extreamly diffrent from each other.
    • Diffrent steppings of the TMxxxx will have diffrent eratta, and severe eratta compaired to "normal" CPUs because a normal CPU can't be used with some of the bugs the TMxxxx can!

    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.

  • the white paper `The technology behind the Crusoe processor' which I cited.

    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.

    eg. about modelling off-chip supporting hardware in software

    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.

    Readers will get much more out of the Spectrum article after they have digested the information in the two links I gave.

    Yes. Or more from those articles after the spectrum article.

  • He's been bitchslaped by the imperial Rob. Check http://slashdot.org/comments.pl?sid= moderation [slashdot.org] for more info.
  • 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.

    Sorry, kind of confusing. I didn't notice the link I gave was a
    mirror site.

  • sorry, I was not clear about what I meant to say, though I think you took what I said extra-wrong.

    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.

  • Who's the idiot? The one who reads a statement as a Question would be considered an idiot. Good luck to you.
  • I doubt it helps with parallelism (SMP I would guess is very difficult
    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...
  • Uh, Windows 95 is 16/32 bit. Win32 however is 32bit.

    Look at NT.
  • Well if you think about it. The Crusoe absolutely *has* to behave like a normal x86 the Software is written for. This absolutly must include the behaviour when using wrong addresses, dividing by zero or other niceties and all those errors have to occure at the right place and the right time (time on the simulated side). Exceptions might be caught. by the software (e.g. to display a bluescreen) and sometimes Programmers depend on it. If I have a division by zero that I catch I want to break off execution at exactly the place the division occurs. Not before and not after. And I can see where this is quite difficult to handle.
    Anyone remembers the /. Discussion when the patents about this problem were revealed?

    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

  • 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

Slashdot Top Deals

A Fortran compiler is the hobgoblin of little minis.

Close