Did the transmeta processor architecture work by binary translation?

Question

Transmeta Corporation produced the Transmeta Crusoe Processor architecture. (Transmeta was also famous for having Linus Torvalds work there at the time.)

We can see from the wikipedia article that the Crusoe processor appears to implements Code Morphing Software. This gives it the ability in theory to execute instructions from other architectures. (eg RISC or Java VM instructions.)

We see a similar pattern in Apple's MacOS Rosetta binary translation software. This enabled software binaries compiled for PowerPC to continue running on the new x86 architecture.

My question is: Did the transmeta processor architecture work by binary translation?

Answer 1

In the Wikipedia article on Transmeta there's a good example for the Code Morphing process, taken from a PDF document (Wayback archived) with even more details:

The operation of Transmeta's code morphing software is similar to the final optimization pass of a conventional compiler. Considering a fragment of 32-bit x86 code:

add eax,dword ptr [esp] // load data from stack, add to eax
add ebx,dword ptr [esp] // ditto, for ebx
mov esi,[ebp]           // load esi from memory
sub ecx,5               // subtract 5 from ecx register

This is first converted simplistically into native instructions:

ld %r30,[%esp]       // load from stack, into temporary
add.c %eax,%eax,%r30 // add to %eax, set condition codes.
ld %r31,[%esp]
add.c %ebx,%ebx,%r31
ld %esi,[%ebp]
sub.c %ecx,%ecx,5

The optimizer then eliminates common sub-expressions and unnecessary condition code operations and, potentially, applies other optimizations such as loop unrolling:

ld %r30,[%esp]     // load from stack only once
add %eax,%eax,%r30
add %ebx,%ebx,%r30 // reuse data loaded earlier
ld %esi,[%ebp]
sub.c %ecx,%ecx,5  // only this last condition code needed

Finally, the optimizer groups individual instructions ("atoms") into long instruction words ("molecules") for the underlying hardware:

ld %r30,[%esp];  sub.c %ecx,%ecx,5
ld %esi,[%ebp];  add %eax,%eax,%r30;  add %ebx,%ebx,%r30

These two VLIW molecules could potentially execute in fewer cycles than the original instructions could on an x86 processor.

So it indeed translates the x86 binary code into the native VLIW binary code. You can call this "binary translation", and it's not an "interpreter", and it's not a "virtual machine" (though this notion is a bit fuzzy; a virtual machine can use various methods to execute actual code, including translating it).

Also note that modern x86 CPUs all use a similar scheme: They translate x86 binary into a more simple, RISC-like code, and then schedule and execute it.

Answer 2

From a comment:

You could argue those components add up to a virtual machine not a translator.

A virtual machine IS a translator. The virtual ISA is translated to run on the physical ISA. The only real distinction is whether and for how long the translations are saved for reuse.

Any microcoded CPU is a virtual machine, in which every instruction is translated on the fly ("interpreted") every time it is encountered — there is no attempt to reuse the translation.

I once worked on the design of a machine (in the early 1980s) that did the translation (from a zero-address "stack machine" ISA to a three-address RISC ISA) when moving instructions from main memory to the instruction cache. As long as the cache line was not replaced, the translation could be reused.

IIRC, the Transmeta actually writes the translations out to a separate area of main memory, allowing them to persist indefinitely. The translation is done by software, rather than hardware, and as long as the original executable file is not modified, the translation can be reused.