robfinch wrote:
The opcode would be executed by the simulator but not by the processor.
One that comes to mind is 'stop' or 'end' simulation.
I think I follow you but it's hard to be certain. Can you expand a little -- flesh out the scenario, please? And, regarding terminology, the "simulator" is the software that runs on the host processor, correct? Still, I don't see that 'stop' and 'end' opcodes would be required. The simulation is essentially a loop that's running, and termination would simply require a conditional branch to exit the loop -- or am I missing something?
As an aside, this is a topic that reminds me of Transmeta's "Crusoe," which was a Very Long Instruction Word processor designed to execute x86 code that had been "code morphed"
at runtime! That is, x86 object code would be examined at run time by the VLIW processor, translated on the fly into native code, then executed by the VLIW cpu. The quality of translation was variable, defaulting to simple, substitution-based translations that could be produced very rapidly. But if an x86 program "hot spot" such as a loop was detected, the priority would shift and the code morphing software (CMS) would invest extra time in producing an optimized translation that
executed with maximum efficiency. IIRC this meant a wider scope, looking at
groups of x86 instructions to find opportunities for optimization. To some extent there's a parallel between what the CMS does in software and what modern, out-of-order, superscalar CPUs do in hardware.
According to
https://en.wikipedia.org/wiki/TransmetaQuote:
Transmeta claims several technical benefits to this approach:
1. As the market leaders Intel and/or AMD would extend the core x86 instruction set, Transmeta could quickly upgrade their product with a software upgrade rather than requiring a respin of their hardware. This method just emphasises the compatibility rather than the performance.
2. Performance and power can be tuned in software to meet market needs.
3. It would be relatively simple to fix hardware design or manufacturing flaws in the hardware using software workarounds.
4. More time could be spent concentrating on enhancing the capabilities of the core or reducing its power consumption without worrying about 33 years of backward compatibility to the x86 architecture.
5. The processor could emulate multiple other architectures, possibly even at the same time. (At its initial Crusoe launch, Transmeta demonstrated pico-Java and x86 running intermixed on the native hardware.)
cheers,
Jeff
http://LaughtonElectronics.com
