4 ms·

This article makes me kind of wonder wether there are processors that understand two or more unrelated instruction encoding sets.

efaref 10y ago
I vaguely recall reading about someone developing a chip that could run both ARM and x86 code. The idea being that it would run ARM code most of the time at low power, and then power up in order to run x86 code when necessary. I don't know if there was any clever sharing of the silicon, or if it was in fact just an x86 core and an ARM core glued together. The only thing I can find on it though is this IEEE document reference: http://ieeexplore.ieee.org/document/6136696/ http://ieeexplore.ieee.org/document/6136696/
- PeCaN 10y ago
  That was Transmeta, which became Nvidia's Project Denver. I think the show stopper is that they were unable to acquire an x86 license. Anyway, it actually ran neither (the core is more like Itanium) and had a separate chip that JIT compiled ARM and x86 to the internal ISA.
  - gsnedders 10y ago
    As far as I'm aware, none of Transmeta's x86 stuff became Project Denver. There was definitely licensing of Transmeta technologies, but I believe that was relatively generally applicable patents (well, generally applicable to ICs). There was, however, given the relative size of the semiconductor industry, some ex-Transmeta staff working on Project Denver. But yes, as far as I'm aware, what killed the x86 support was licensing.
    - PeCaN 10y ago
      Project Denver still JITs ARM to an internal VLIW architecture I believe. It's pretty Transmeta-like.
      - gsnedders 10y ago
        Yes, they do. And the influence of Transmeta is clearly there, even if it's not a direct descendent. Ultimately the x86 licensing issue just killed the x86 decode step, AFAIK.
- gsnedders 10y ago
  There was also the PPC615 in the mid-90s, done by IBM, which was socket-compatible with the Pentium, and could execute at least PPC32, PPC64, and x86_32 natively (I'm not clear on whether it supported x86_16): the decode step for x86_32, AIUI, essentially decoded it into PPC instructions. It was meant to be competitive with the Pentium in x86-mode, and could change between ISAs at the thread level, I believe. Ultimately it was scrapped as people in charge believed Intel were about to move away from IA-32 and the industry would follow to IA-64 with its IA-32 compatibility.
wolfgke 10y ago
What do you consider as "unrelated"? For example modern ARMv8 cores understand 3 instruction sets: AArch32, Thumb2 and AArch64. AArch32 and Thumb may be related, but AArch64 is more different (no conditional execution, more registers etc. for example). Though you would perhaps still consider them as related. EDIT: Similarly, modern x86-64 cores support at least three instruction sets: x86-16 (real mode), x86-32 (protected mode) and x86-64 (long mode). These are related, but at least I claim that x86-16 and x86-64 are very different in practise. A perhaps better example is Jazelle on older ARM cores, which supported exectuting most of Java VM's instruction set directly on the processor. Or another example: The instruction set of many processors is separated into several parts that work and encode quite differently. For example the x87 instructions are stack-based instead of register-based. Or I have heard that AltiVec instructions encode and work quite differently from normal PowerPC instructions. The only reason why these are not considered as different instruction sets is that they lie in the same opcode space. If you consider instruction sets that "just lie in the same opcode space, but are otherwise mostly unrelated" as unrelated, then there are some instruction sets that evolved as hybrids of different instruction sets for controlling different functional units. Or another example is many SoCs contain additional coprocessors and ARM's instruction set contains instruction for controlling them. These coprocessors execute different instruction set. But perhaps you would consider this not as "one processor" but rather several communicating processors on one chip. TLDR: Define what you mean with "[one] processor" and with "unrelated" in terms of encoding of instructions.
- legulere 10y ago
  Your examples are all instruction sets that were developed with the idea in mind that they run together with the other instruction sets. What I meant with unrelated is instruction sets that have been developed independently and were not meant to run on the same cpu from the beginning. For instance a cpu that supports both the Risc-V and the Power architecture.
  - umanwizard 10y ago
    Look again -- he mentioned Jazelle, does that fit the bill?
rwmj 10y ago
The NEC V20/V30 chips were 8086 clones, but unusually they had an 8080 emulation mode. I recall that the registers were common, eg. %bx (8086) and BC (8080) were the same register when you switched between modes. The "killer feature" was that you could run CP/M programs on your PC. As long as the CP/M programs weren't "naughty" and didn't use Z80 instructions (a different superset of 8080). CP/M itself had system calls which emulated the Z80 instructions (mainly LDIR), which could be "accelerated" if the processor was a real Z80, but of course programs occasionally ignored this and just used the Z80 instructions directly. https://en.wikipedia.org/wiki/NEC_V20 https://en.wikipedia.org/wiki/NEC_V20
pcwalton 10y ago
Depending on your definition of "processor", most SoCs that have an integrated CPU and GPU may fit the bill.

efaref 10y ago

I vaguely recall reading about someone developing a chip that could run both ARM and x86 code. The idea being that it would run ARM code most of the time at low power, and then power up in order to run x86 code when necessary. I don't know if there was any clever sharing of the silicon, or if it was in fact just an x86 core and an ARM core glued together. The only thing I can find on it though is this IEEE document reference: http://ieeexplore.ieee.org/document/6136696/ http://ieeexplore.ieee.org/document/6136696/

PeCaN 10y ago
That was Transmeta, which became Nvidia's Project Denver. I think the show stopper is that they were unable to acquire an x86 license. Anyway, it actually ran neither (the core is more like Itanium) and had a separate chip that JIT compiled ARM and x86 to the internal ISA.
- gsnedders 10y ago
  As far as I'm aware, none of Transmeta's x86 stuff became Project Denver. There was definitely licensing of Transmeta technologies, but I believe that was relatively generally applicable patents (well, generally applicable to ICs). There was, however, given the relative size of the semiconductor industry, some ex-Transmeta staff working on Project Denver. But yes, as far as I'm aware, what killed the x86 support was licensing.
  - PeCaN 10y ago
    Project Denver still JITs ARM to an internal VLIW architecture I believe. It's pretty Transmeta-like.
    - gsnedders 10y ago
      Yes, they do. And the influence of Transmeta is clearly there, even if it's not a direct descendent. Ultimately the x86 licensing issue just killed the x86 decode step, AFAIK.
gsnedders 10y ago
There was also the PPC615 in the mid-90s, done by IBM, which was socket-compatible with the Pentium, and could execute at least PPC32, PPC64, and x86_32 natively (I'm not clear on whether it supported x86_16): the decode step for x86_32, AIUI, essentially decoded it into PPC instructions. It was meant to be competitive with the Pentium in x86-mode, and could change between ISAs at the thread level, I believe. Ultimately it was scrapped as people in charge believed Intel were about to move away from IA-32 and the industry would follow to IA-64 with its IA-32 compatibility.

wolfgke 10y ago

What do you consider as "unrelated"? For example modern ARMv8 cores understand 3 instruction sets: AArch32, Thumb2 and AArch64. AArch32 and Thumb may be related, but AArch64 is more different (no conditional execution, more registers etc. for example). Though you would perhaps still consider them as related. EDIT: Similarly, modern x86-64 cores support at least three instruction sets: x86-16 (real mode), x86-32 (protected mode) and x86-64 (long mode). These are related, but at least I claim that x86-16 and x86-64 are very different in practise. A perhaps better example is Jazelle on older ARM cores, which supported exectuting most of Java VM's instruction set directly on the processor. Or another example: The instruction set of many processors is separated into several parts that work and encode quite differently. For example the x87 instructions are stack-based instead of register-based. Or I have heard that AltiVec instructions encode and work quite differently from normal PowerPC instructions. The only reason why these are not considered as different instruction sets is that they lie in the same opcode space. If you consider instruction sets that "just lie in the same opcode space, but are otherwise mostly unrelated" as unrelated, then there are some instruction sets that evolved as hybrids of different instruction sets for controlling different functional units. Or another example is many SoCs contain additional coprocessors and ARM's instruction set contains instruction for controlling them. These coprocessors execute different instruction set. But perhaps you would consider this not as "one processor" but rather several communicating processors on one chip. TLDR: Define what you mean with "[one] processor" and with "unrelated" in terms of encoding of instructions.

legulere 10y ago
Your examples are all instruction sets that were developed with the idea in mind that they run together with the other instruction sets. What I meant with unrelated is instruction sets that have been developed independently and were not meant to run on the same cpu from the beginning. For instance a cpu that supports both the Risc-V and the Power architecture.
- umanwizard 10y ago
  Look again -- he mentioned Jazelle, does that fit the bill?

rwmj 10y ago

The NEC V20/V30 chips were 8086 clones, but unusually they had an 8080 emulation mode. I recall that the registers were common, eg. %bx (8086) and BC (8080) were the same register when you switched between modes. The "killer feature" was that you could run CP/M programs on your PC. As long as the CP/M programs weren't "naughty" and didn't use Z80 instructions (a different superset of 8080). CP/M itself had system calls which emulated the Z80 instructions (mainly LDIR), which could be "accelerated" if the processor was a real Z80, but of course programs occasionally ignored this and just used the Z80 instructions directly. https://en.wikipedia.org/wiki/NEC_V20 https://en.wikipedia.org/wiki/NEC_V20

pcwalton 10y ago

Depending on your definition of "processor", most SoCs that have an integrated CPU and GPU may fit the bill.