3 ms·

Couldn't the decode unit be translated into software that converts legacy software on the fly? It seems to me that the outdated instruction set is detrimental t

Couldn't the decode unit be translated into software that converts legacy software on the fly? It seems to me that the outdated instruction set is detrimental to innovation and power efficiency. Also how high is the overhead in terms of chip space and power that the decoder incurs, vs. one that has to decode a simpler instruction set? My limited understanding is that the number of instructions issued per cycle heavily depend on the instruction set and decode speed.

thrownaway2424 13y ago
You just suggested that decode is a bottleneck, and that decode should be done in software, in the same paragraph.
- orbifold 13y ago
  Not really, I suggested to decode once at the start of the application, or even at compile time for that matter in order to gain legacy support. A cpu has to decode the instruction stream no matter what, if the decoding is complicated by the fact that there is no close correspondence between the instructions and the hardware this is a potential bottleneck.
klodolph 13y ago
> Couldn't the decode unit be translated into software that converts legacy software on the fly? Not only is it possible, but it has been done. Look up the Transmeta Efficeon. Note that it's not RISC-like but VLIW (which I like to think of as "the next thing after RISC").
dazam 13y ago
Transmeta tried to do exactly what you are proposing i.e, have a software layer (Code Morphing) translate the x86 instruction stream to their native VLIW instruction set. They didn't go very far.
- orbifold 13y ago
  In the case of Intel the underlying architecture is really fast, whereas my understanding is that Transmeta failed because the VLIW architecture did not really work out. If Intel Cpus use a Risc like architecture nothing would prevent static translation to it, which was not feasible for Transmeta cpus. The x86 software layer would then only be there to preserve backwards compatibility.

thrownaway2424 13y ago

You just suggested that decode is a bottleneck, and that decode should be done in software, in the same paragraph.

orbifold 13y ago
Not really, I suggested to decode once at the start of the application, or even at compile time for that matter in order to gain legacy support. A cpu has to decode the instruction stream no matter what, if the decoding is complicated by the fact that there is no close correspondence between the instructions and the hardware this is a potential bottleneck.

klodolph 13y ago

> Couldn't the decode unit be translated into software that converts legacy software on the fly? Not only is it possible, but it has been done. Look up the Transmeta Efficeon. Note that it's not RISC-like but VLIW (which I like to think of as "the next thing after RISC").

dazam 13y ago

Transmeta tried to do exactly what you are proposing i.e, have a software layer (Code Morphing) translate the x86 instruction stream to their native VLIW instruction set. They didn't go very far.

orbifold 13y ago
In the case of Intel the underlying architecture is really fast, whereas my understanding is that Transmeta failed because the VLIW architecture did not really work out. If Intel Cpus use a Risc like architecture nothing would prevent static translation to it, which was not feasible for Transmeta cpus. The x86 software layer would then only be there to preserve backwards compatibility.