Unless Win 3.11 or DOS are not "standard x86-compatible operating systems", the note on the TM3120:
Systems based on this solution are capable of executing all standard x86-compatible operating system
sure seems to imply that the TM3120 can run Windows 3.11 and DOS code.
So IMHO -- and I assume you'd agree --Transmeta really needs to clarify this issue better.
You assume incorrectly - the people who seem to think that they haven't stated pretty clearly that both chips are completely x86-compatible seem to me to be trying, for some unknown reason, to read something into Transmeta's statements that isn't there, and I don't think it's particularly worth Transmeta's time and energy to worry about people who choose to read "the complete range of x86-based operating systems" or "Fully x86 compatible" in non-obvious ways.
Sun partnered with (I think) Fujtsu to build the first SPARC on a 20K gate-array
Yes, the first SPARCs were fabbed by Fujitsu; the first full-custom SPARC (7C601) was done by Cypress.
because IBM managed to market a RISC baised machine before Sun's SPARC got out the door
As I remember, the RT PC came out after SPARC - I remember people waiting in fear at Sun because they didn't know whether the RT was going to crush them like a bug.
That CPU had actually been around internal to IBM for a number of years, but never turned into a computer product (I think it came out of hte typewriter labs)
It was called ROMP, for Research and Office Microprocessor; I guess the "Office" part indicates that it was intended for office equipment such as word processors, etc..
Mot started a crash program to devlop the "88k", which DG eventually used for some ill-fated Unix workstations (The AvIlon i think).
Right - it was used in the DG Aviion machines, as well as the nes I mentioned.
I seem to remember hearing (from a comp.arch posting by John Mashey, I think) that Motorola pitched the 88K to MIPS as well as to Sun.
eventually some big complicated Apple-IBM-Mot deal created the PowerPC
...based on IBM's POWER (Performance Optimized With Enhanced RISC - yes, really; some marketoon must've gotten a bonus for that one) architecture, which was their attempt, after the ROMP and a second generation thereof; the first POWER chip (RIOS) did a fair bit better than the ROMP, performance-wise.
HP's PA showed up and battled the Alpha for a long time
I think the Precision Architecture antedated Alpha.
As far as I can tell, there is a FPGA(Field Programmable Gate Array)-like property to the setup as well.
As far as I can tell, there's no such thing. The chips' hardware doesn't appear to be reconfigurable; they have fixed VLIW instruction sets.
The chips will run, at the lowest level, software that takes code for an instruction set such as x86, and translate it to the native fixed instruction set for the chip on which it's running.
It's more like changeable microcode than like FPGA-style changeable hardware, but microcode is generally used to interpret an instruction set, rather than to translate it to a native instruction set not interpreted by microcode (no, the System/38 and AS/400 aren't an exception; the vertical "microcode" was just software, called "microcode" for legal reasons, as per Frank Soltis' Inside the AS/400 book).
I can only get audio so I might be missing something
You're not missing anything. Both chips are x86-compatible (in that the binary-to-binary translation software turns x86 code into the native code for the chip on which it's running, and runs it), and can run any x86 OS (assuming the OS can handle the rest of the system into which it's put, that is). The slower one could run Windows (or BeOS, or *BSD, or Solaris, or...), and the faster one could run Linux (or BeOS, or *BSD, or Solaris, or...).
This sounds much like the 88000 that was supposed to replace the 68000 in the Mac, Amiga, Atari, & SUN stuff before Motorola went RISC.
Motorola first "went RISC" with the 88000. I forget whether they pitched the 88000 to Sun, but Sun didn't bite - they rolled their own, SPARC.
What happened to that project?
It went into some machines - I think Omron had an 88K workstation, and Encore had 88K-based superminis - but, for better or worse, didn't catch on big enough to survive; Motorola eventually dropped it after joining up with IBM and Apple to do PowerPC.
However, I don't see how this was like the 88000, which was a RISC chip, and which didn't use the RISC instruction set solely as
a target for a binary-to-binary translator;
the instruction set in which said translator ran;
but provided it as the instruction set that assembler-language programmers and compilers generated.
The Code Morphing Software (CMS): enables the user to have any x86 OS on the HPC, not just windows.
True of a PC running just about any x86 processor, not just a Crusoe (as long as the system doesn't have features that some OSes don't support and that have to be supported, e.g. USB keyboards, which aren't, as far as I know, supported by one well-known PC OS...
...Windows NT 4.0).
App development - any x86 app and OS runs now! very, very cool. If you don't like windows, you can develop linux or BeOS apps, and it will run. Out of the box, this thing is running everything you have and will come to have.
True of a PC running just about any x86 processor, not just a Crusoe.
And, the possiblities inidicate being able to run different OS apps at the same time (Java and Win running simultaneously was mentioned - I'm sure more is possible).
Did they really claim that they could do this any better than any other x86 processor? You can run Java apps on Windows on x86 (or Linux on x86, or...) now - as far as I know, you can even do it with a JIT compiler.
Can I run a win32 and linux binary similtaniously without rebooting?
Sure, if it runs under WINE, or if you run VMware on the OS the machine booted under, and run the other OS under VMware, or something such as that.:-)
What Crusoe provides is a processor that looks, from the standpoint of the OS and stuff running atop it, just like any other x86 processor, but that implements the x86 instruction set by dynamically translating code from x86 to the native instruction set of the particular chip. It's not providing, from what I've seen on the Transmeta Web site, any magical ability to run two OSes simultaneously, or to run apps from two OSes simultaneously, beyond what you can do on any other x86-compatible processor.
It seems to me that DEC (now Compaq) already has the claim on "code morphing".
Digital have done a binary-to-binary translator that (as I remember) can instrument the translated code (or otherwise observe its behavior) and retranslate based on that, but:
they weren't the first people to do binary-to-binary translation;
they don't necessarily have a patent on the instrumenting or other observation, or retranslation based on feedback, ideas.
But code-morphing makes it sound as if I could throw Solaris on the little bastard. Or OS X. Or BeOS.
Definitely true for Solaris and BeOS, given that there are versions of both of those OSes that run on the instruction set from which Transmeta's binary-to-binary translation code translates.
MacOS X is another matter, unless Apple release an x86 version of it.
Perhaps the underlying VLIW engines on the two chips aren't so specialized to serve as targets for translation from x86 that SPARC-to-native or PowerPC-to-native compilers could be written, but I wouldn't hold my breath waiting for those translators - I'd punt on MacOS X and get x86 versions of Solaris or BeOS instead.
I don't think the version of IE on CE can run "standard" IE plug-ins
Given that IE plugins tend, as far as I know, to be x86 Win32 code, and that not all CE machines have x86-compatible processors in them, at least some of them almost certainly can't run those plugins.
A machine running on a Crusoe processor could (in theory) run Linux+Netscape (or Win98+IE, or Be, etc) and use "standard" plugins.
A machine running an x86-compatible processor from a supplier other than Transmeta could do that, too - but presumably the idea is that such a machine might have higher power consumption than one might like (although there is at least one mobile device with an x86 processor in it - the Nokia 9000 family of mobile phones on steroids - although I think it's an embedded x86 and may not be capable of running most x86 OSes; I think the 9000's run GeoWorks).
The first time a chunk of code is run, there's a performance hit as it's translated to the native instruction set for the particular chip on which it's running. The translated code is cached, so the next time it's run, if it's still in the cache of translated code, there's no performance hit for translation.
Full x86 compatibility, with two different models. The more expensive, faster chip will support all x86 apps including 16 bit ones, the less expensive one dumps the 16 bit because (as Transmeta made clear) there really isn't a set of legacy apps out there.
If it dumps support for the 16-bit instructions, it doesn't offer "full x86 compatibility".
The TM3120 is compatible with the complete range of x86-based operating systems, including those offered by Microsoft and Linux suppliers. Transmeta expects that Linux will be the primary operating system for mobile Internet devices.
so they don't "dump" the 16-bit instructions in the less-expensive chip. It may not handle 16-bit code as efficiently the more-expensive chip, just as a product from another maker of x86-compatible chips punted on handling 16-bit code efficiently (but said maker had to fix that in the Pentium II because the P6 was to be used in PC's, not in appliances without the problem of legacy apps; the PPro might have been able to get away with it as it was primarily intended for high-end machines running NT and Win32 apps).
AFAIK, all the examples you name are software emulation.
You don't know far enough. FX!32, at least, did binary-to-binary translation, and at least some JVMs translate Java bytecodes to native code. (I don't know whether the 68K emulation in PowerPC MacOS ever did binary-to-binary translation.)
There are other examples of binary-to-binary translation as well - the IBM System/38 and AS/400 (compilers for which generated a high-level very CISC pseudo-instruction set; that code gets translated into the native instruction set), a 68K Smalltalk done by L. Peter Deutsch that translated Smalltalk bytecodes into 68K code (caching the results of the translation), binary-to-binary translators that turned 16-bit stack-machine HP 3000 code into 32-bit PA-RISC HP 3000 code, and probably others.
Binary-to-binary translation isn't a Transmeta invention; the hardware assistance they provide for it is, as far as I know, as is the idea that the native instruction set isn't even exposed to the OS or the BIOS/PROM monitor.
The TM3120 is compatible with the complete range of x86-based operating systems, including those offered by Microsoft and Linux suppliers. Transmeta expects that Linux will be the primary operating system for mobile Internet devices.
and says of the higher-speed processor:
The TM5400 is compatible with the complete range of x86-based operating systems. This includes all versions of Linux, as well as Microsoft's popular Windows 98, Windows NT, and Windows 2000 operating systems.
They don't explicitly mention FreeBSD - or NetBSD, or OpenBSD, or BSD/OS, or SCO UNIX, or SCO Unixware, or SCO Xenix, or OS/2, or BeOS, or Solaris, or Coherent, or... - but those are all part of the "complete range of x86-based operating systems".
As far as the BIOS/PROM monitor, the OS, the applications, etc. are concerned, it's just another x86 processor.
Transmeta's "code morphing" techniques, on the other hand, do something a little more intelligent. They start by translation of x86 to native instructions. So you are running native code, with an up-front penalty for translation. Then they apply selective optimizations to tune the translated code to the native design as needed.
The first part of this is, of course, hardly unique to Transmeta; binary-to-binary translation's been around for ages (dating back at least to the IBM System/38, compilers for which generated a very CISCy pseudo-instruction set that got translated to the native instruction set by code running on the machine; the AS/400's continue to do this, which made it easier for them to switch from the older S/38 and AS/400's with their 360-ish instruction set to the newer AS/400's with an extended PowerPC), and it was also used, I think, by HP to migrate users from the 16-bit stack-machine HP 3000's to the 32-bit PowerPC HP 3000's, and Digital's^H^H^H^H^H^H^H^H^HCompaq's FX!32 translates x86 Win32 programs to Alpha Win32 programs.
A Smalltalk implementation for the 68K, by L. Peter Deutsch (yes, Mr. Ghostscript), translated Smalltalk bytecodes to native 68K instructions, and, of course, Java just-in-time compilers do that as well.
I have the impression that FX!32, at least, would do post-execution optimization of the generated code based on profiling.
What I think is new about Transmeta's stuff is
the only instruction set they expose, even to the OS and the BIOS/PROM monitor, is x86;
they have hardware features to make it easier for the binary-to-binary translation software to generate high-performance code.
Yes, he's one of the investors. The mere fact that one of the founders of Microsoft invested in them doesn't ipso facto mean that they will make one of their processors incapable of running OSes not from Microsoft; given that the chip presents an x86-compatible interface to non-Transmeta code running on it, the TM5400, as Transmeta said on their Web site, "...is compatible with the complete range of x86-based operating systems. This includes all versions of Linux, as well as Microsoft's popular Windows 98, Windows NT, and Windows 2000 operating systems."
Someone correct me if I am wrong, but one point was the ability to upgrade the instruction set w/ a software upgrade. This means that all the opcodes and whatnot are not stored on the chip so what would stop anyone from just taking the instruction set from the tm3120 and load them up to the tm5400.
You're wrong about what that ability means.
The native instruction set of the processor is hard-wired.
However, the only code in that instruction set is
the binary-to-binary translation code;
code generated by that binary-to-binary translation code
"Upgrading the instruction set" would change the instruction set for OSes, applications, etc. that the machine would be willing to run - and that instruction set is the same for both chips; it's x86.
So Linux on a 700mhz sounds very possible.
Of course it is - Linux does exist for x86 processors.:-) They quite explicitly say that Linux will run on the TM5400 (the faster of the two machines, that being the "700 MHz version" - the Crusoe processor family page says quite explicitly:
The TM5400 is compatible with the complete range of x86-based operating systems. This includes all versions of Linux, as well as Microsoft's popular Windows 98, Windows NT, and Windows 2000 operating systems.
it was mentioned near the end that the vliw instructions AND the code morphing software on the two chips are different and NOT binary compatible.
The instruction sets are different - and the binary-to-binary translation software would then be different because it has to translate to a different instruction set.
Fully x86 compatible: they run x86 applications just like conventional x86 microprocessors.
PC compatible: Crusoe processors already include portions of the traditional PC support chipset, and they run all popular PC operating systems.
so they're "binary-compatible" to the extent that they can both run x86 code.
So possibly no Linux on the 700Mhz version?
Umm, Linux is a "popular PC operating system", is it not? Given that, the above indicates that Crusoe processors, plural, can run Linux.
For that matter, the Crusoe processor family page says quite explictly of the TM 5400 (that being the chip to which you're referring):
The TM5400 is compatible with the complete range of x86-based operating systems. This includes all versions of Linux, as well as Microsoft's popular Windows 98, Windows NT, and Windows 2000 operating systems.
Since Intel has said that their next proc is VLIW, it looks like TransMeta's VLIW proc is leading them...
...except that the IA-64 instruction set will be available to programmers and compilers, whilst the instruction sets of the Transmeta chips are not.
"No mention was made regarding the connection to the Internet...that was just assumed to be there. But I have yet to hear about any affordable and sufficiently fast connection via mobile unit... How will they address this, or will they just leave it up to other companies to solve this general problem?"
I think you are refering to the fact that the translation units can be upgraded via software. Software which comes over the internet:-)
Eh? I think he's referring to fast inexpensive wireless Internet access - or the lack of same. There are other reasons to want your mobile device to have fast Internet access than the desire to get upgrades to the binary-to-binary translation software over the Internet (although, unless they've added an "upload new translation software" instruction to the x86 instruction set, and translate that into code to replace the translation code, I'm not sure whether a box with a Transmeta processor would be able to "upgrade the translation units via software" - the technical white paper on the Transmeta Web site implies that, to all the software running on a machine with a Transmeta processor, including the OS and the PROM monitor/BIOS, it looks just like an x86 processor).
In what sense? There's probably not a current "UNIX" on the planet that has code that's identical to the last UNIX released by UNIX System Laboratory, unless you count Unixware (on the grounds that SCO bought USL from Novell who bought it from AT&T) - the other major commercial licensees have generally added a fair bit of their own code, and the Berkeley folk replaced rather a lot of it as well.
Linux never started with AT&T code, but I'm not sure how much that matters at this point.
By the way, (never checked into it yet) but does Linux support USB yet?
Yes, there's some support in the current 2.2.x kernel. I'm not sure how it compares with the *BSD support; in the drivers/usb directory of 2.2.13 there appear to be keyboard, mouse, and audio drivers.
Perhaps the person to whom your responding meant that the interface intrinsic to the tool - i.e., the semantics of Makefiles - were "confusing and lame", and therefore that "writing a new interface" would mean "writing a new tool".
Sometimes incremental improvement of existing tools merely involves moving closer to a local optimum in the solution space, and avoiding a better local optimum somewhere else in the solution space.
That's why I think that this competition isn't ipso facto a bogus idea - perhaps people won't come up with something better, perhaps they'll come up with something that's a little better but not enough to supplant the existing tools (NOTE: the availability of the new tools does not mean the old tools will go away! It's not as if you won't still be able to use make and autoconf.), but perhaps they might come up with something that has an underlying model that's significantly better, so that the new tools are easier to use, or more powerful, or more powerful and easier to use (e.g., it may be easier to make use of the tools' power).
No, I don't know offhand what such a tool might look like - but that in no way constitutes an indication that no such different-and-better tool is impossible.
Premise: programmable logic can optimally execute algorithms for which source code is available
Premise: the Transmeta patents are patents on stuff they're actually going to do with Crusoe.
Implications: the chip won't necessarily have any programmable logic whatsoever; software running on the chip, in the chip's quite-possibly-fixed native instruction set, will translate other instruction sets into the native instruction set and run it.
Is this interesting enough that I should elaborate further?
Interesting? Yes.
Relevant to Crusoe? I suspect not. We'll probably find out on the 19th, but I suspect all the folk who've been going on about FPGAs and reconfigurable hardware blah blah blah will have to eat their words....
The chip will rewrite its internal wiring using logic gates
I have yet to see a single piece of evidence to suggest that Crusoe will necessarily be able to "rewrite its internal wiring"; the Transmeta patents suggest that the machine has a fixed native instruction set, and that other instruction sets are handled by binary-to-binary translation, by software, of code for other instruction sets.
Slashdot Mirror
I.e., Windows Terminal Server is "a UNIX way to approach the design of NT"?
Unless Win 3.11 or DOS are not "standard x86-compatible operating systems", the note on the TM3120:
sure seems to imply that the TM3120 can run Windows 3.11 and DOS code.
You assume incorrectly - the people who seem to think that they haven't stated pretty clearly that both chips are completely x86-compatible seem to me to be trying, for some unknown reason, to read something into Transmeta's statements that isn't there, and I don't think it's particularly worth Transmeta's time and energy to worry about people who choose to read "the complete range of x86-based operating systems" or "Fully x86 compatible" in non-obvious ways.
Yes, the first SPARCs were fabbed by Fujitsu; the first full-custom SPARC (7C601) was done by Cypress.
As I remember, the RT PC came out after SPARC - I remember people waiting in fear at Sun because they didn't know whether the RT was going to crush them like a bug.
It was called ROMP, for Research and Office Microprocessor; I guess the "Office" part indicates that it was intended for office equipment such as word processors, etc..
Right - it was used in the DG Aviion machines, as well as the nes I mentioned.
I seem to remember hearing (from a comp.arch posting by John Mashey, I think) that Motorola pitched the 88K to MIPS as well as to Sun.
...based on IBM's POWER (Performance Optimized With Enhanced RISC - yes, really; some marketoon must've gotten a bonus for that one) architecture, which was their attempt, after the ROMP and a second generation thereof; the first POWER chip (RIOS) did a fair bit better than the ROMP, performance-wise.
I think the Precision Architecture antedated Alpha.
As far as I can tell, there's no such thing. The chips' hardware doesn't appear to be reconfigurable; they have fixed VLIW instruction sets.
The chips will run, at the lowest level, software that takes code for an instruction set such as x86, and translate it to the native fixed instruction set for the chip on which it's running.
It's more like changeable microcode than like FPGA-style changeable hardware, but microcode is generally used to interpret an instruction set, rather than to translate it to a native instruction set not interpreted by microcode (no, the System/38 and AS/400 aren't an exception; the vertical "microcode" was just software, called "microcode" for legal reasons, as per Frank Soltis' Inside the AS/400 book).
You're not missing anything. Both chips are x86-compatible (in that the binary-to-binary translation software turns x86 code into the native code for the chip on which it's running, and runs it), and can run any x86 OS (assuming the OS can handle the rest of the system into which it's put, that is). The slower one could run Windows (or BeOS, or *BSD, or Solaris, or...), and the faster one could run Linux (or BeOS, or *BSD, or Solaris, or...).
Motorola first "went RISC" with the 88000. I forget whether they pitched the 88000 to Sun, but Sun didn't bite - they rolled their own, SPARC.
It went into some machines - I think Omron had an 88K workstation, and Encore had 88K-based superminis - but, for better or worse, didn't catch on big enough to survive; Motorola eventually dropped it after joining up with IBM and Apple to do PowerPC.
However, I don't see how this was like the 88000, which was a RISC chip, and which didn't use the RISC instruction set solely as
but provided it as the instruction set that assembler-language programmers and compilers generated.
True of a PC running just about any x86 processor, not just a Crusoe (as long as the system doesn't have features that some OSes don't support and that have to be supported, e.g. USB keyboards, which aren't, as far as I know, supported by one well-known PC OS...
...Windows NT 4.0).
True of a PC running just about any x86 processor, not just a Crusoe.
Did they really claim that they could do this any better than any other x86 processor? You can run Java apps on Windows on x86 (or Linux on x86, or...) now - as far as I know, you can even do it with a JIT compiler.
Sure, if it runs under WINE, or if you run VMware on the OS the machine booted under, and run the other OS under VMware, or something such as that. :-)
What Crusoe provides is a processor that looks, from the standpoint of the OS and stuff running atop it, just like any other x86 processor, but that implements the x86 instruction set by dynamically translating code from x86 to the native instruction set of the particular chip. It's not providing, from what I've seen on the Transmeta Web site, any magical ability to run two OSes simultaneously, or to run apps from two OSes simultaneously, beyond what you can do on any other x86-compatible processor.
Digital have done a binary-to-binary translator that (as I remember) can instrument the translated code (or otherwise observe its behavior) and retranslate based on that, but:
Definitely true for Solaris and BeOS, given that there are versions of both of those OSes that run on the instruction set from which Transmeta's binary-to-binary translation code translates.
MacOS X is another matter, unless Apple release an x86 version of it.
Perhaps the underlying VLIW engines on the two chips aren't so specialized to serve as targets for translation from x86 that SPARC-to-native or PowerPC-to-native compilers could be written, but I wouldn't hold my breath waiting for those translators - I'd punt on MacOS X and get x86 versions of Solaris or BeOS instead.
Given that IE plugins tend, as far as I know, to be x86 Win32 code, and that not all CE machines have x86-compatible processors in them, at least some of them almost certainly can't run those plugins.
A machine running an x86-compatible processor from a supplier other than Transmeta could do that, too - but presumably the idea is that such a machine might have higher power consumption than one might like (although there is at least one mobile device with an x86 processor in it - the Nokia 9000 family of mobile phones on steroids - although I think it's an embedded x86 and may not be capable of running most x86 OSes; I think the 9000's run GeoWorks).
The first time a chunk of code is run, there's a performance hit as it's translated to the native instruction set for the particular chip on which it's running. The translated code is cached, so the next time it's run, if it's still in the cache of translated code, there's no performance hit for translation.
If it dumps support for the 16-bit instructions, it doesn't offer "full x86 compatibility".
However, the Crusoe processor family page says that the TM3120 does offer full x86 compatibility:
so they don't "dump" the 16-bit instructions in the less-expensive chip. It may not handle 16-bit code as efficiently the more-expensive chip, just as a product from another maker of x86-compatible chips punted on handling 16-bit code efficiently (but said maker had to fix that in the Pentium II because the P6 was to be used in PC's, not in appliances without the problem of legacy apps; the PPro might have been able to get away with it as it was primarily intended for high-end machines running NT and Win32 apps).
You don't know far enough. FX!32, at least, did binary-to-binary translation, and at least some JVMs translate Java bytecodes to native code. (I don't know whether the 68K emulation in PowerPC MacOS ever did binary-to-binary translation.)
There are other examples of binary-to-binary translation as well - the IBM System/38 and AS/400 (compilers for which generated a high-level very CISC pseudo-instruction set; that code gets translated into the native instruction set), a 68K Smalltalk done by L. Peter Deutsch that translated Smalltalk bytecodes into 68K code (caching the results of the translation), binary-to-binary translators that turned 16-bit stack-machine HP 3000 code into 32-bit PA-RISC HP 3000 code, and probably others.
Binary-to-binary translation isn't a Transmeta invention; the hardware assistance they provide for it is, as far as I know, as is the idea that the native instruction set isn't even exposed to the OS or the BIOS/PROM monitor.
FreeBSD runs on x86-compatible processors, does it not?
The Crusoe processor family page on the Transmeta Web site says of the lower-speed processor:
and says of the higher-speed processor:
They don't explicitly mention FreeBSD - or NetBSD, or OpenBSD, or BSD/OS, or SCO UNIX, or SCO Unixware, or SCO Xenix, or OS/2, or BeOS, or Solaris, or Coherent, or... - but those are all part of the "complete range of x86-based operating systems".
As far as the BIOS/PROM monitor, the OS, the applications, etc. are concerned, it's just another x86 processor.
The first part of this is, of course, hardly unique to Transmeta; binary-to-binary translation's been around for ages (dating back at least to the IBM System/38, compilers for which generated a very CISCy pseudo-instruction set that got translated to the native instruction set by code running on the machine; the AS/400's continue to do this, which made it easier for them to switch from the older S/38 and AS/400's with their 360-ish instruction set to the newer AS/400's with an extended PowerPC), and it was also used, I think, by HP to migrate users from the 16-bit stack-machine HP 3000's to the 32-bit PowerPC HP 3000's, and Digital's^H^H^H^H^H^H^H^H^HCompaq's FX!32 translates x86 Win32 programs to Alpha Win32 programs.
A Smalltalk implementation for the 68K, by L. Peter Deutsch (yes, Mr. Ghostscript), translated Smalltalk bytecodes to native 68K instructions, and, of course, Java just-in-time compilers do that as well.
I have the impression that FX!32, at least, would do post-execution optimization of the generated code based on profiling.
What I think is new about Transmeta's stuff is
Yes, he's one of the investors. The mere fact that one of the founders of Microsoft invested in them doesn't ipso facto mean that they will make one of their processors incapable of running OSes not from Microsoft; given that the chip presents an x86-compatible interface to non-Transmeta code running on it, the TM5400, as Transmeta said on their Web site, "...is compatible with the complete range of x86-based operating systems. This includes all versions of Linux, as well as Microsoft's popular Windows 98, Windows NT, and Windows 2000 operating systems."
You're wrong about what that ability means.
The native instruction set of the processor is hard-wired.
However, the only code in that instruction set is
"Upgrading the instruction set" would change the instruction set for OSes, applications, etc. that the machine would be willing to run - and that instruction set is the same for both chips; it's x86.
Of course it is - Linux does exist for x86 processors. :-) They quite explicitly say that Linux will run on the TM5400 (the faster of the two machines, that being the "700 MHz version" - the Crusoe processor family page says quite explicitly:
The instruction sets are different - and the binary-to-binary translation software would then be different because it has to translate to a different instruction set.
However, as the Compatibility page on the Transmeta web site says:
so they're "binary-compatible" to the extent that they can both run x86 code.
Umm, Linux is a "popular PC operating system", is it not? Given that, the above indicates that Crusoe processors, plural, can run Linux.
For that matter, the Crusoe processor family page says quite explictly of the TM 5400 (that being the chip to which you're referring):
...except that the IA-64 instruction set will be available to programmers and compilers, whilst the instruction sets of the Transmeta chips are not.
Eh? I think he's referring to fast inexpensive wireless Internet access - or the lack of same. There are other reasons to want your mobile device to have fast Internet access than the desire to get upgrades to the binary-to-binary translation software over the Internet (although, unless they've added an "upload new translation software" instruction to the x86 instruction set, and translate that into code to replace the translation code, I'm not sure whether a box with a Transmeta processor would be able to "upgrade the translation units via software" - the technical white paper on the Transmeta Web site implies that, to all the software running on a machine with a Transmeta processor, including the OS and the PROM monitor/BIOS, it looks just like an x86 processor).
In what sense? There's probably not a current "UNIX" on the planet that has code that's identical to the last UNIX released by UNIX System Laboratory, unless you count Unixware (on the grounds that SCO bought USL from Novell who bought it from AT&T) - the other major commercial licensees have generally added a fair bit of their own code, and the Berkeley folk replaced rather a lot of it as well.
Linux never started with AT&T code, but I'm not sure how much that matters at this point.
Yes, there's some support in the current 2.2.x kernel. I'm not sure how it compares with the *BSD support; in the drivers/usb directory of 2.2.13 there appear to be keyboard, mouse, and audio drivers.
Perhaps the person to whom your responding meant that the interface intrinsic to the tool - i.e., the semantics of Makefiles - were "confusing and lame", and therefore that "writing a new interface" would mean "writing a new tool".
Sometimes incremental improvement of existing tools merely involves moving closer to a local optimum in the solution space, and avoiding a better local optimum somewhere else in the solution space.
That's why I think that this competition isn't ipso facto a bogus idea - perhaps people won't come up with something better, perhaps they'll come up with something that's a little better but not enough to supplant the existing tools (NOTE: the availability of the new tools does not mean the old tools will go away! It's not as if you won't still be able to use make and autoconf.), but perhaps they might come up with something that has an underlying model that's significantly better, so that the new tools are easier to use, or more powerful, or more powerful and easier to use (e.g., it may be easier to make use of the tools' power).
No, I don't know offhand what such a tool might look like - but that in no way constitutes an indication that no such different-and-better tool is impossible.
Premise: the Transmeta patents are patents on stuff they're actually going to do with Crusoe.
Implications: the chip won't necessarily have any programmable logic whatsoever; software running on the chip, in the chip's quite-possibly-fixed native instruction set, will translate other instruction sets into the native instruction set and run it.
Interesting? Yes.
Relevant to Crusoe? I suspect not. We'll probably find out on the 19th, but I suspect all the folk who've been going on about FPGAs and reconfigurable hardware blah blah blah will have to eat their words....
I have yet to see a single piece of evidence to suggest that Crusoe will necessarily be able to "rewrite its internal wiring"; the Transmeta patents suggest that the machine has a fixed native instruction set, and that other instruction sets are handled by binary-to-binary translation, by software, of code for other instruction sets.