"Don't do any of that expensive engineering/research, we just want to make you the next SCO!"

Okay so a company that started up promising fundamental and revolutionary changes, who got most of their kudos on slashdot after they hired St Linus of Finland. Have done (as the plaintiff points out) bugger all else, and is now facing the stark reality of economics.

In other news: Emperor's new clothes put on ebay, but fail to make the reserve.

Maybe Transmeta should close up shop, but at least the patents and R&D could be put to use instead of creating another SCO-esque IP troll. Maybe IBM should buy them. If I recall, IBM has worked with Transmeta in the past, and the recent Power chips have been in serious need of some low-power R&D love.

Classic example of why American business has problems. Companies throw money on their CxOs as if they are really the reason for success. Heck this is a perfect example, the company is falling on it's face and they reward the CxOs with millions above their large salaries?

Outright moronic, this investor couldn't be more correct.

I was really worried but after listening to Travis, there is still hope, there is intelligence on planet earth. They need to start prosecuting these monopolies but then to not do so is the Republican way.

PS go get em Travis!

is anybody else reminded of that SGI/Microsoft thing a while ago?

So the alien tech didn't work out so well after all?

This won't be the first US-managed company that appears to exist for the sole purpose of lining the execs pockets. BTDT. Sigh.

Nail, Head

exactly on both counts

USA business model, lets try to make money from nothing and pay worthless exec's millions to do so.

hmmm our economy is tanking, wonder why

An Investment Banking shop getting all hot under the collar 'cos a few execs have trousered massive bonuses for doing f***-all?

What's next, Turkeys campaigning for an extended Christmas?

Transmeta failed purely because their technology was/is inadequate. The code morphing and low power usage ideals were impressive, but the main reason they failed was due to an inability to capitalise on code morphing, and to provide sufficient performance.

Retail laptops/machines did actually make it to market, and every single review said 'far too slow, battery life not that special'.

VIA have managed to hang in there with low power, custom form factor and sensible custom silicon (ensuring their chips can decode MPEG2/4 and do cryptographic processing). Transmeta really should be able to do the same.

They want to wipe out the expected $20 million operating expenses for the year, and last year Transmeta paid its lawyer a bonus of $10 million plus its CEO and CFO $12 million. So last year's bonuses exceed this year's entire operating expenses??????

If I were a stock holder I would be plenty angry. I would want my money out in as best form as I could get it. It doesn't sound as if Transmeta is really doing anything except "monetizing its intellectual property" anyway, its just that they are giving the money to their CEO, CFO, and lawyer mates, and not the shareholders.

Comparing the situation to SGI/Microsoft is interesting, again it was the shareholders that got screwed after the CEO seemed to cave in. Funny about where he got his next job.

While you're right about what the CPU's problems were, methinks you somewhat underestimate the challenge against all odds (or common sense) involved in it.

The fact is, all modern CPUs since the (IIRC) K5 already do code-morphing in silicon. It's a micro-coded design, although everyone calls it RISC-ified (or some similar thing) just for buzzword sake. Any modern CPU translates complex instructions, as seen by a compiler or program, to several simpler internal instructions and then executes those. They even have far more registers for those instructions than you see from the outside.

So Intel and AMD _already_ do some sort of code morphing, and did it long before Transmeta.

And I think you'll find it's quite a challenge to do that in software faster than dedicated silicon can do it.

But wait, here comes the best part. Any modern CPU has a very dynamic and advanced approach to managing that queue of micro-instructions. If one needs data that's not arrived yet, they can be reordered in flight, they can change lanes, etc. And it can even take leaps of faith on prediction, and generate code based on what will _probably_ happen (e.g., this particular loop most often jump to the start, and only rarely exit, so let's go ahead and predict that it will jump there this time too), knowing that it can invalidate the pipeline and try again if that's false. Etc.

That's all stuff that a code morpher can't do. If it predicted an optimization wrong, there's no way to have instructions reordered in memory, or switch lanes in a VLIW program, or lots of other things. It can just wait out for the data (wasted cycles) or recompile the code (a heck of a lot _more_ expensive.)

Branch prediction is an even bigger bitch when you compile that code instead of having some silicon generate it on the fly. Pretty much you _can't_ do it. Your code will have to assume that when you reach a conditional jump, it could go either way, and it must work right either way. You can't assume it'll always go one way, and recompile if you missed, because recompiling is a huge performance hit, far exceeding any advantages you might get from betting on one branch in advance.

Basically it's a freakin' miracle that it even worked as well as it did. They must have some pretty smart people there.

But they're already pushing the limits of what's even theoretically possible with that design. _That_ is their problem.

Basically saying that they should capitalize on that and focus on making it work as fast as dedicated silicon is... well, sorta like saying that they should have focused on finding the Philosopher's Stone and turning lead into gold. It's just not going to happen. It's not even theoretically possible. Sorry.

"The fact is, all modern CPUs since the (IIRC) K5 already do code-morphing in silicon."

You mean like Itanium, POWER6, and almost all SPARC chips? Oh wait, those are all in-order native implementations.

There certainly are advantages to scheduling and optimizing in hardware. However, there are advantages to doing it in software, too. For example, software can consider a much larger instruction window, and can perform more radical transformations, since optimization need not take place concurrently with execution. These days, it's pretty cheap to have an idle (hardware) thread that can do optimization while the main program is running.

And software has been doing many of the things you claim impossible for years: speculative code motion, profile feedback based optimizations, and so on. There are even some run time systems that will detect that program behavior has changed over time, and reoptimize accordingly.