Code Morphing - The end of incompatible architectures?

[Elledan]

As all of you probably know, code morphing is the process through which a CPU converts a certain type of instructions (e.g., x86) into its own set of instructions. One CPU which uses this technology is the Crusoe of Transmeta.

Now is my question, would it be possible to allow such a code-morphing CPU to convert more than just one type of instructions, i.e., so that by 'flipping a switch', you can change it from an x86 compatible CPU into an IA-64 compatible CPU, or a G4 one?

Also, how far can one go with replacing transistors (hardware) with software? Performance aside, would it be possible to construct a CPU with only a minimum of transistors and further just software which would fulfill the functions of the 'left-out' transistors?

One last remark, although some of you will undoubtly have realized this by now: code morphing is a fascinating technology =)

 

[CTho9305]

you might find this to be of interest

edit: grammar

 

[Elledan]

<< you might find this to be of interest

edit: grammar >>


Hmm.. that was a bit over my head, I guess, but I think I understand some of it. Care to elaborate a bit on it?

 

[CTho9305]

its a joke... the idea is to make a 500-transistor 32-bit processor. You create a REALLY simple processor, with minimal instructions. Then, you write some "microcode" for it which emulates, say, x86 instructions.

For example, lets say we only implemented addition, but want to pretend the processor can subtract. the microcode reads a subtract instruction, then turns it into "actual" instructions - invert all the bits of the 2nd operand, add one to it, then add the two together. you use microcode to simulate everything you don't have. the microcode sets the instruction set that is visible to the programmer - that is how it ties into your question. the joke processor cuts the transistors to the absolute minimum, and does EVERYTHING in software.

now with a processor like this, you could have different microcode programs - one that handles IA32, one that handles PPC, one that handles IA64, etc. In theory, that would be the exact thing you are asking for.

However, for performance reasons, you would probably not want to use that 500T idea , but rather design it to handle most of the "common" (as in, common to all instruction sets) instructions truly in hardware. I would guess that if you modified the fetch/decode stages of an x86 processor, you could probably get it to do PPC without many additional changes. I'm not at all familiar with the PPC instruction set though.

a cool idea would be to have an extra (non x86, non PPC) instruction that changes the instruction set realtime - so you could simultaneously run software for different architectures. when the OS switches tasks, it checks if the instruction set is correct, and if not, changes it using the extra instruction.

disclaimer: hopefully that gives you a basic idea of how it might be done. I doubt all of it is completely accurate. I've already edited it 3x

 

[zephyrprime]

Code morphing is just the marketing name that Transmeta made up so it could get venture capitalists enthused about instruction translation. I read an article that interviewed the pres of Transmeta and explained the origin of the word "code morphing". I found it fascinating that those venture capitalist guys just couldn't understand instruction translating.

The idea of instruction translating was already in use before "code morphing". Digital had software for the Alpha that let it run ia32 software and it was the same basic thing as code morphing. The idea no doubt predates Digital also.

 

[CTho9305]

arguably IBM had been doing it even earlier (system 360/370? earlier?)... each machine in a given series could run the apps as the other machines, even though the internals were sometimes totally different. This was done using microcode - but if you take this as an example of code morphing, then every chip using microcode does it to a certain degree - even athlons and pentiums.

 

[Shalmanese]

Hmm, maybe I am not understanding this but isnt code morphing just a fancy word for really efficient emulator.

 

[Elledan]

<< Hmm, maybe I am not understanding this but isnt code morphing just a fancy word for really efficient emulator. >>

In a way it is.

BTW, I found this article rather interesting: tecChannel : Transmeta Crusoe im Detail

It's about the Crusoe CPU of Transmeta. It's in German, though

 

[CTho9305]

<< Hmm, maybe I am not understanding this but isnt code morphing just a fancy word for really efficient emulator. >>


yeah, but the emulation is done at a hardware level. so you give it a cool name and people buy your stock

edit: well, not really hardware... its a combination of software/hardware. IIRC, the software part takes 4 meg of ram or so - the OS you run sees 4 meg less than what is actually present.

 

[Shalmanese]

I am confused, how do you do emulation in hardware. Isnt the whole point that nothing is hard wired so that it can emulate any system.

I guess what you are saying is that it can do certain X86,, PPC etc. instuctions in hardware but other stuff requires software.

Is this right?

 

[Elledan]

<< I am confused, how do you do emulation in hardware. Isnt the whole point that nothing is hard wired so that it can emulate any system.

I guess what you are saying is that it can do certain X86,, PPC etc. instuctions in hardware but other stuff requires software.

Is this right? >>


The CPU itself can use any instruction set, but it uses microcode (with the Crusoe CPU it's stored on the mainboard in a 4 MB Flash chip) to convert a certain instruction set into its own.

 

[malapala]

Your favourite 6th or 7th generation x86-processor does this too. K7, P6 and P4 doesn't really execute x86-code, but translates instructions to "uOps" which are easier to implement. Simple x86-instructions is decoded by hard wires, and complex ones is decoded by looking for the uOp-stream in a "microcode ROM" on the chip. On the K7, instructions that translates to 3 uOps or more is done by "software" (as in microcode rom), and I think the P4 uses the ROM for instructions longer than 4 uops.

I haven't read about the crusoe, but I guess that it does the same thing as the P4, but it uses microcode RAM for all instructions. I also believe that it stores the already decoded instructions in a cache, just like the ETC on Pentium 4, so that it only need to decode the instruction once, even if it is executed thousands of times in a loop. I have also heard rumors that the crusoe optimizes the uOps on the fly like a JIT Compiler, but I don't know how. Maybe the decoder is "real" software and not just a dictionary.

 

[Elledan]

<< Your favourite 6th or 7th generation x86-processor does this too. K7, P6 and P4 doesn't really execute x86-code, but translates instructions to "uOps" which are easier to implement. Simple x86-instructions is decoded by hard wires, and complex ones is decoded by looking for the uOp-stream in a "microcode ROM" on the chip. On the K7, instructions that translates to 3 uOps or more is done by "software" (as in microcode rom), and I think the P4 uses the ROM for instructions longer than 4 uops. >>

Hmm... I didn't know about this. Thanks for sharing!



<< I haven't read about the crusoe, but I guess that it does the same thing as the P4, but it uses microcode RAM for all instructions. >>


That is correct.


<< I also believe that it stores the already decoded instructions in a cache, just like the ETC on Pentium 4, so that it only need to decode the instruction once, even if it is executed thousands of times in a loop. >>


Yup, that's the Translation Cache.


<< I have also heard rumors that the crusoe optimizes the uOps on the fly like a JIT Compiler, but I don't know how. Maybe the decoder is "real" software and not just a dictionary. >>

I would be interested to learn more about this too.

 

[CTho9305]

<< Your favourite 6th or 7th generation x86-processor does this too. K7, P6 and P4 doesn't really execute x86-code, but translates instructions to "uOps" which are easier to implement. Simple x86-instructions is decoded by hard wires, and complex ones is decoded by looking for the uOp-stream in a "microcode ROM" on the chip. On the K7, instructions that translates to 3 uOps or more is done by "software" (as in microcode rom), and I think the P4 uses the ROM for instructions longer than 4 uops.

I haven't read about the crusoe, but I guess that it does the same thing as the P4, but it uses microcode RAM for all instructions. I also believe that it stores the already decoded instructions in a cache, just like the ETC on Pentium 4, so that it only need to decode the instruction once, even if it is executed thousands of times in a loop. I have also heard rumors that the crusoe optimizes the uOps on the fly like a JIT Compiler, but I don't know how. Maybe the decoder is "real" software and not just a dictionary. >>



welcome to the forums