5 ms·

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 lo

by 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.

by efaref 10y ago

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.