7 ms·

While the conversion from x86 to Intel's internal microcode obviously adds complexity, internally Intel has been a RISC load/store architecture since 2006. Sinc

While the conversion from x86 to Intel's internal microcode obviously adds complexity, internally Intel has been a RISC load/store architecture since 2006. Since ARM moved to ARMv8, I groaningly refer to v8 as "x86 v2" with most implementations with ridiculous pipelines and OoO execution. The only actually good ARMv8 implementation I've seen doesn't actually implement ARMv8 at all internally... NVIDIA's (now basically dead) Denver architecture does Transmeta style codemorphing to support ARMv8 instructions while having a much simpler (and efficient) internal architecture.

setpatchaddress 10y ago
What would you rather have seen ARM do for a 64-bit ISA expansion? (Genuine question; I have no opinion.)
- trsohmers 10y ago
  Going through them would be a book in itself (The ARMv8 reference manual is itself a couple thousand pages, which I have only gone through a fraction of). I think RISC-V is the closest thing to what I would like in a simple general purpose ISA, even though it is not perfect (no branch delay slots, no post modifies/register writebacks, don't like the immediate encoding). It is a hell of a lot better than the mess ARM made, and the basic (IMAFD) instruction reference can be kept to a single page ;)
  - rayiner 10y ago
    Wait you like branch delay slots?!
    - trsohmers 10y ago
      I love branch delay slots, and they are a key feature for getting highest performance in the architecture I am working on... if you have things like guaranteed latency and static scheduling (like we do with the REX Neo architecture), delay slots are VERY useful in tight loops. I understand not including them in a general purpose design with branch prediction, but I'm not a fan of branch prediction and its effects on determinism.
      - coderjames 10y ago
        I'd never heard of the Rex Neo until your post. Looks very interesting!
  - stephencanon 10y ago
    > no branch delay slots We fought that battle 15 years ago, and delay slots lost (for general-purpose CPUs).
monocasa 10y ago
Eh, OoOE and pipelines in the dozens of stages make a lot of sense at the gate count we're talking about. Sure, you won't get the best pure performance/watt, but you'll get a nice balance of raw performance and perf/watt if you play your cards right (which I'd argue Apple did with their cores, and ARM is finally catching up with their A73s it looks like). And I'm not a super huge fan of the raw ISA of the chip being hidden from you a la DAISY/Crusoe/Denver. And that's coming from someone who's haevily inspired by their techniques while writing a high performance machine to machine JIT. I'd love raw access to their underlying VLIW code though (maybe similar to 90s era Apple nanokernel with machine tranlator that allows you to start a native process context).
- bogomipz 10y ago
  When you say "raw ISA" and "underlying VLIW code"are you referring to the microcops/mirocde or is this something specific to ARM chips?
  - monocasa 10y ago
    I'm talking about IBM's DAISY, Transmeta's Crusoe, and Nvidia's Denver. These are more or less fairly standard VLIW machines that are designed to only run a JIT compiler for another machine architecture (PowerPC, x86, and ARM respectively). This JITed code is the only other code running on the machine, so they basically look like native versions of the architectures they emulate. Edit: These machines also do a lot of cool stuff under the hood. DAISY's native binary format looks more like a CFG than we pure instruction steam. The Crusoe has some really sweet exposed speculation hardware. I'm sure Denver does some really cool stuff too, there's just not a whole lot of publicly available information on it.
    - bogomipz 10y ago
      Ah neat, I think I remember hearing about the transmeta one back when. These weren't terribly successful though right? What is the acronym "CFG", I wasn't able to find that anywhere.
scriptdevil 10y ago
Denver isn't close to dead. I work in the Denver team at NVIDIA. If you mean market adoption, yes - Nexus 9 is the only major device to have shipped with Denver cores as of today. But development is still very active internally.
- lgeek 10y ago
  Somewhat off topic, but I wish NVIDIA published more information about Denver's DBO and the reasoning behind some design decisions. For example the company line is to just generate 'decent code' and let the DBO take care of it [0], but that clearly doesn't always work in practice [1], which requires a lot of trial & error and some reverse engineering to generate good code for it. Also, the decision to always invalidate the translation when writing to an executable page (or whatever other super slow operation is done in that case) seems odd (and affects the performance of some JIT approaches) since ARM software is expected to explicitly flush the caches when modifying code anyway. [0] https://www.youtube.com/watch?v=oEuXA0_9feM https://www.youtube.com/watch?v=oEuXA0_9feM [1] https://github.com/ssvb/tinymembench/wiki/Nexus-9-(Tegra-TK1-T132---Denver) https://github.com/ssvb/tinymembench/wiki/Nexus-9-(Tegra-TK1...
lgeek 10y ago
> Since ARM moved to ARMv8, I groaningly refer to v8 as "x86 v2" I'll have to disagree, I think ARM mostly did the right thing with the A64 instruction set. The AArch32 instruction sets were just getting ridiculous (just having multiple instruction sets for one architecture is pretty messed up), with A32, T32 and a bunch of other extensions (ThumbEE, Jazelle) which pretty much no one used. In addition, the A32 and T32 instruction sets have grown organically over time, with new instructions being crammed in any unused / invalid space, which is how we ended up with one encoding doing this one thing, except if one register is the SP or PC, then that is a whole other instruction or with immediate values being split up over 2, 3, 4 fields. Also, a few features had turned out to be pretty bad ideas: for example access to the PC as a general purpose register is overly complicated to implement in OOO cores (verification cost) and comes with performance penalties, but it still had to be supported; the IT instruction is another fun one, especially in the context of dealing with exceptions. A64 pretty much takes the set of instructions which has emerged over time, removes the bits which are not suitable any more or were bad ideas in retrospect, fits them cleanly in a new encoding space and removes some of the flexibility which was getting in the way (e.g. VFP having either 16 or 32 double precision registers). I expect AArch32 to be gone from most high performance implementations in a few years, with a software DBT option remaining available for legacy software which still hasn't been ported, which is when the implementers will be able to fully benefit from having a simplified AArch64 compared to AArch32.
- mrpippy 10y ago
  > I expect AArch32 to be gone from most high performance implementations in a few years Apple has been requiring iOS apps to include 64-bit binaries for more than a year, and in iOS 10 they're publicly shaming 32-bit apps [1] on launch. Wouldn't be surprised at all if 32-bit support is gone from iOS and Apple's SoCs by iOS 12 / 2018. [1] http://appleinsider.com/articles/16/06/15/ios-10-warns-users-when-opening-legacy-apps-not-encoded-in-64-bit http://appleinsider.com/articles/16/06/15/ios-10-warns-users...

setpatchaddress 10y ago

What would you rather have seen ARM do for a 64-bit ISA expansion? (Genuine question; I have no opinion.)

trsohmers 10y ago
Going through them would be a book in itself (The ARMv8 reference manual is itself a couple thousand pages, which I have only gone through a fraction of). I think RISC-V is the closest thing to what I would like in a simple general purpose ISA, even though it is not perfect (no branch delay slots, no post modifies/register writebacks, don't like the immediate encoding). It is a hell of a lot better than the mess ARM made, and the basic (IMAFD) instruction reference can be kept to a single page ;)
- rayiner 10y ago
  Wait you like branch delay slots?!
  - trsohmers 10y ago
    I love branch delay slots, and they are a key feature for getting highest performance in the architecture I am working on... if you have things like guaranteed latency and static scheduling (like we do with the REX Neo architecture), delay slots are VERY useful in tight loops. I understand not including them in a general purpose design with branch prediction, but I'm not a fan of branch prediction and its effects on determinism.
    - coderjames 10y ago
      I'd never heard of the Rex Neo until your post. Looks very interesting!
- stephencanon 10y ago
  > no branch delay slots We fought that battle 15 years ago, and delay slots lost (for general-purpose CPUs).

monocasa 10y ago

Eh, OoOE and pipelines in the dozens of stages make a lot of sense at the gate count we're talking about. Sure, you won't get the best pure performance/watt, but you'll get a nice balance of raw performance and perf/watt if you play your cards right (which I'd argue Apple did with their cores, and ARM is finally catching up with their A73s it looks like). And I'm not a super huge fan of the raw ISA of the chip being hidden from you a la DAISY/Crusoe/Denver. And that's coming from someone who's haevily inspired by their techniques while writing a high performance machine to machine JIT. I'd love raw access to their underlying VLIW code though (maybe similar to 90s era Apple nanokernel with machine tranlator that allows you to start a native process context).

bogomipz 10y ago
When you say "raw ISA" and "underlying VLIW code"are you referring to the microcops/mirocde or is this something specific to ARM chips?
- monocasa 10y ago
  I'm talking about IBM's DAISY, Transmeta's Crusoe, and Nvidia's Denver. These are more or less fairly standard VLIW machines that are designed to only run a JIT compiler for another machine architecture (PowerPC, x86, and ARM respectively). This JITed code is the only other code running on the machine, so they basically look like native versions of the architectures they emulate. Edit: These machines also do a lot of cool stuff under the hood. DAISY's native binary format looks more like a CFG than we pure instruction steam. The Crusoe has some really sweet exposed speculation hardware. I'm sure Denver does some really cool stuff too, there's just not a whole lot of publicly available information on it.
  - bogomipz 10y ago
    Ah neat, I think I remember hearing about the transmeta one back when. These weren't terribly successful though right? What is the acronym "CFG", I wasn't able to find that anywhere.

scriptdevil 10y ago

Denver isn't close to dead. I work in the Denver team at NVIDIA. If you mean market adoption, yes - Nexus 9 is the only major device to have shipped with Denver cores as of today. But development is still very active internally.

lgeek 10y ago
Somewhat off topic, but I wish NVIDIA published more information about Denver's DBO and the reasoning behind some design decisions. For example the company line is to just generate 'decent code' and let the DBO take care of it [0], but that clearly doesn't always work in practice [1], which requires a lot of trial & error and some reverse engineering to generate good code for it. Also, the decision to always invalidate the translation when writing to an executable page (or whatever other super slow operation is done in that case) seems odd (and affects the performance of some JIT approaches) since ARM software is expected to explicitly flush the caches when modifying code anyway. [0] https://www.youtube.com/watch?v=oEuXA0_9feM https://www.youtube.com/watch?v=oEuXA0_9feM [1] https://github.com/ssvb/tinymembench/wiki/Nexus-9-(Tegra-TK1-T132---Denver) https://github.com/ssvb/tinymembench/wiki/Nexus-9-(Tegra-TK1...

lgeek 10y ago

> Since ARM moved to ARMv8, I groaningly refer to v8 as "x86 v2" I'll have to disagree, I think ARM mostly did the right thing with the A64 instruction set. The AArch32 instruction sets were just getting ridiculous (just having multiple instruction sets for one architecture is pretty messed up), with A32, T32 and a bunch of other extensions (ThumbEE, Jazelle) which pretty much no one used. In addition, the A32 and T32 instruction sets have grown organically over time, with new instructions being crammed in any unused / invalid space, which is how we ended up with one encoding doing this one thing, except if one register is the SP or PC, then that is a whole other instruction or with immediate values being split up over 2, 3, 4 fields. Also, a few features had turned out to be pretty bad ideas: for example access to the PC as a general purpose register is overly complicated to implement in OOO cores (verification cost) and comes with performance penalties, but it still had to be supported; the IT instruction is another fun one, especially in the context of dealing with exceptions. A64 pretty much takes the set of instructions which has emerged over time, removes the bits which are not suitable any more or were bad ideas in retrospect, fits them cleanly in a new encoding space and removes some of the flexibility which was getting in the way (e.g. VFP having either 16 or 32 double precision registers). I expect AArch32 to be gone from most high performance implementations in a few years, with a software DBT option remaining available for legacy software which still hasn't been ported, which is when the implementers will be able to fully benefit from having a simplified AArch64 compared to AArch32.

mrpippy 10y ago
> I expect AArch32 to be gone from most high performance implementations in a few years Apple has been requiring iOS apps to include 64-bit binaries for more than a year, and in iOS 10 they're publicly shaming 32-bit apps [1] on launch. Wouldn't be surprised at all if 32-bit support is gone from iOS and Apple's SoCs by iOS 12 / 2018. [1] http://appleinsider.com/articles/16/06/15/ios-10-warns-users-when-opening-legacy-apps-not-encoded-in-64-bit http://appleinsider.com/articles/16/06/15/ios-10-warns-users...