4 ms·

This is a reasonable, short overview of the programmer-visible side of changes in A64. For those interested, there's an another side. A64 drops all the feature

This is a reasonable, short overview of the programmer-visible side of changes in A64. For those interested, there's an another side. A64 drops all the features of the ISA (inline variable shifts, conditional execution, variable-width instructions) that are hard to implement in a fast, high-power CPU. If a cpu is to not have any 32-bit ARM compatibility, there's no reason one couldn't make a 4GHz 4-wide superscalar one based on A64.

btian 13y ago
There is one - power consumption.
- Tuna-Fish 13y ago
  Well yes, it won't fit on a phone. The point was that making a CPU that rivals current desktop cpus is possible using A64, so long as you are willing to expand your power budget to meet them.
justincormack 13y ago
Yes its interesting to see a really new ISA, much newer than the old high end contenders like Sparc and Power.
ajross 13y ago
This is true, but that last sentence is a doozy. The AArch64 ISA drops that stuff. The A7 CPU, which much remain compatible with legacy code, must not. So yes, a theoretical CPU would have a much easier design task, but in the real world we'll never see one. And in any case: there's another reasonably well-known company out there with an even cruftier ISA making 4+GHz 6-wide superscalar cores with backwards 32 (and 16!) bit compatibility modes. Instruction decode is the sort of thing programmers understand, so we tend to get hung up on it when talking about CPUs. It's really not a meaningful design limitation to a CPU core implemented with hundreds of millions of transistors.
- protomyth 13y ago
  I'm not so sure we won't see a AArch64 only version. A server version would be fine with dropping the 32-bit part.
  - ghshephard 13y ago
    As would a Desktop/Laptop which have no legacy 32 bit applications/drivers to be concerned about.
- plorkyeran 13y ago
  I would not be surprised if an iPhone without support for 32-bit apps came out within a few years. Apple has been pretty willing to break existing apps with iOS updates, so there's no real expectation that something which works today will continue to work indefinitely with no changes.
  - christoph 13y ago
    This. Apple's track record proves that they are more than happy to drop anything more than a couple of years old if it means general forward progression. My real bugbear is that to some extent they've created the modern day IE6 by not updating Safari on the old iPad. Also, if you look at some legacy iOS apps on the Appstore (designed pre 6.x), they are pretty much 100% broken on 6.x+
    - deleted 13y ago
      [deleted]
- Tuna-Fish 13y ago
  > in the real world we'll never see one. Not from Apple, maybe. I know there is at least one in the works for the server market. > And in any case: there's another reasonably well-known company out there with an even cruftier ISA making 4+GHz 6-wide superscalar cores with backwards 32 (and 16!) bit compatibility modes. Instruction decode is the sort of thing programmers understand, so we tend to get hung up on it when talking about CPUs. You absolutely can implement a fast core out of almost any ISA (just look at IBM System z!) if you have sufficient resources. The point is that A64 is amenable to being made into a fast CPU without Intel-scale design effort.
mappu 13y ago
Wait, AArch64 really drops conditional execution? When i was learning x86 assembly, discovering CMOV was fantastic, drastically simplified all my code (versus cmp+je+hundreds of extraneous labels.. notwithstanding macros). The fact ARM could do that for almost all instructions was one of the main reasons in my mind why ARM was considered a "cleaner" architecture than x86. EDIT: crisis averted, a comment further down ( https://news.ycombinator.com/item?id=6458457 https://news.ycombinator.com/item?id=6458457 ) clarifies the change.
- rwmj 13y ago
  Wait, AArch64 really drops conditional execution? Some, yes (but it is retained in 32 bit mode). The reason it was dropped is that it's hard to implement. It adds an implicit data dependency between an instruction and previous results. In a pipeline, the results of previous instructions aren't available immediately, there is usually a delay of many cycles before a "previous" instruction actually finishes and retires. So if your "current" instruction needs the result of the one before it, it's going to have to wait, stalling the pipeline. Adding extra dependencies such as instructions that depend on the state of the flags register is not desirable. IIRC it also makes register renaming hard when one implicit register (the flags) is heavily used.

btian 13y ago

There is one - power consumption.

Tuna-Fish 13y ago
Well yes, it won't fit on a phone. The point was that making a CPU that rivals current desktop cpus is possible using A64, so long as you are willing to expand your power budget to meet them.

justincormack 13y ago

Yes its interesting to see a really new ISA, much newer than the old high end contenders like Sparc and Power.

ajross 13y ago

This is true, but that last sentence is a doozy. The AArch64 ISA drops that stuff. The A7 CPU, which much remain compatible with legacy code, must not. So yes, a theoretical CPU would have a much easier design task, but in the real world we'll never see one. And in any case: there's another reasonably well-known company out there with an even cruftier ISA making 4+GHz 6-wide superscalar cores with backwards 32 (and 16!) bit compatibility modes. Instruction decode is the sort of thing programmers understand, so we tend to get hung up on it when talking about CPUs. It's really not a meaningful design limitation to a CPU core implemented with hundreds of millions of transistors.

protomyth 13y ago
I'm not so sure we won't see a AArch64 only version. A server version would be fine with dropping the 32-bit part.
- ghshephard 13y ago
  As would a Desktop/Laptop which have no legacy 32 bit applications/drivers to be concerned about.
plorkyeran 13y ago
I would not be surprised if an iPhone without support for 32-bit apps came out within a few years. Apple has been pretty willing to break existing apps with iOS updates, so there's no real expectation that something which works today will continue to work indefinitely with no changes.
- christoph 13y ago
  This. Apple's track record proves that they are more than happy to drop anything more than a couple of years old if it means general forward progression. My real bugbear is that to some extent they've created the modern day IE6 by not updating Safari on the old iPad. Also, if you look at some legacy iOS apps on the Appstore (designed pre 6.x), they are pretty much 100% broken on 6.x+
  - deleted 13y ago
    [deleted]
Tuna-Fish 13y ago
> in the real world we'll never see one. Not from Apple, maybe. I know there is at least one in the works for the server market. > And in any case: there's another reasonably well-known company out there with an even cruftier ISA making 4+GHz 6-wide superscalar cores with backwards 32 (and 16!) bit compatibility modes. Instruction decode is the sort of thing programmers understand, so we tend to get hung up on it when talking about CPUs. You absolutely can implement a fast core out of almost any ISA (just look at IBM System z!) if you have sufficient resources. The point is that A64 is amenable to being made into a fast CPU without Intel-scale design effort.

mappu 13y ago

Wait, AArch64 really drops conditional execution? When i was learning x86 assembly, discovering CMOV was fantastic, drastically simplified all my code (versus cmp+je+hundreds of extraneous labels.. notwithstanding macros). The fact ARM could do that for almost all instructions was one of the main reasons in my mind why ARM was considered a "cleaner" architecture than x86. EDIT: crisis averted, a comment further down ( https://news.ycombinator.com/item?id=6458457 https://news.ycombinator.com/item?id=6458457 ) clarifies the change.

rwmj 13y ago
Wait, AArch64 really drops conditional execution? Some, yes (but it is retained in 32 bit mode). The reason it was dropped is that it's hard to implement. It adds an implicit data dependency between an instruction and previous results. In a pipeline, the results of previous instructions aren't available immediately, there is usually a delay of many cycles before a "previous" instruction actually finishes and retires. So if your "current" instruction needs the result of the one before it, it's going to have to wait, stalling the pipeline. Adding extra dependencies such as instructions that depend on the state of the flags register is not desirable. IIRC it also makes register renaming hard when one implicit register (the flags) is heavily used.