Maybe you could come up with a compiler that converts Java code to 51 hex. After all its a lot like C, and you would not have to run the enormous overheads of a JVM, how ever "tiny" it might be.

But I read about Transmeta's Crusoe chip, which has something called the Code Morphing Software. This code morphing s/w actually reads hex from its code memory, and at run-time translates the hex code into equivalent native machine language instructions. So the whole system itself is like a JVM, there is no partitioning between the H/W and the system S/W. The whole thing is a overhead, of course, but its highly optimized and parallelized in hardware wherever possible.

Last I read, they had code morphing software for 8086 instructions, i.e the Code Mprphing Software could "understand" 86 hex. This system also allows you to run programs compiled for different processors at the same time, i.e it decides at run-time which instruction set is supported. Maybe they could make the Code Morphing Software compatible with Java ByteCode.

Ok all this is kinda off-topic, but they could come up with something like that for the 8051, or any microcontroller. How about code-morphing HARDWARE? A pretty challenging VLSI project actually, possible too. Here's how I think it may work:

This Code Morphing (CM) chip would be placed on the bus in between the target uC and the code memory (ROM, flash wotever). It would route the addresses generated by the uC to the code memory, and translate the returned contents into hex code of the target uC, and send the translated version back to the uC. This is pretty much what the JVM does, but this virtual machine is a HARDWARE virutal machine, i.e. the mapping between various instruction sets is HARD-WIRED.

Ok, maybe we could make it more generic, and endow the CM chip with two large register sets and/or memory areas, which can be dynamically loaded with the mapping between instruction sets. In fact maybe later on we could add a number of code-mappings onto a single device. Since all the translation happens in hardware, there can be virtually no overheads. It will be especially easy when dealing with similar instruction sets, like CISC and RISC. since we have software cross-assemblers, it is conceivable that they can be implemented in hardware.

Of course, there are a LOT of issues here, and operation may be slowed down slightly, but it IS possible. The biggest problem would be mapping between specific registers, but we can leave that to the application programmer or the source assembler / compiler. There can be some default mapping provided

The applications of such a device would be very interesting indeed. A code-morph for Java bytecode is only the beginning.... Backward Compatibility will not be an issue. This, I understand, is keeping them from using all the features on the latest Intel chips. We can load protocol-translation mappings to, transperently converting from, say RS-232 to I2C (we already have hardware TCP/IP stacks). We could port the hex code itself to other processors, instead of re-writing the source code and re-compiling. Programmers can include useful language features from other instructions sets without having to worry about implementing them in the target processor code.

Ok that's enough speculation for now, but could anyone well-versed in VLSI design tell me how feasible this is? I don't think it will be very difficult to implement at all, but the design of such a chip would be very challenging. Also I need to know from experienced embedded systems designers how truly useful such a device would be, and would all the effort of developing it pay off, in terms of finance and intellectual property rights.

kundi