4 ms·

At the risk of sounding like a broken record, I like what ARM did with AArch64. AArch64 is not entirely a clean break with 32-bit ARM, but it eliminated a lot o

At the risk of sounding like a broken record, I like what ARM did with AArch64. AArch64 is not entirely a clean break with 32-bit ARM, but it eliminated a lot of legacy mistakes and is generally a radical shift in the direction of a clean RISC design. Unlike x86-64, which piled 64-bit support on top of the existing ISA, keeping most of the legacy intact, AArch64 aggressively addressed problems such as conditional execution, PC-as-register, the small register file, LDM/STM complexity, barrel shifter complexity, etc. Most importantly, 32-bit mode is an optional feature not mandated by the ARM architecture, hopefully paving the way to dropping the legacy stuff entirely in the future.

mikepurvis 9y ago
ARM doesn't have to support legacy binaries in the same way that the wintel ecosystem does. I don't think it's really comparable.
- runeks 9y ago
  Is it really a problem to emulate this in software, though (honest question)? As far as I can see, if compability with old software is the only concern, then losing 80% performance isn't really a problem since the new CPU is probably 5x faster anyway. Thus making up for the loss, so the old executable runs as fast on a new CPU, using emulation, as it did running in hardware on the old one. So all we'd really lose is a speedup for legacy software -- and who really needs to play Wolfenstein 3D at 80,000 FPS, as long as it works?
  - dtech 9y ago
    Yes, it is a problem. The new CPU won't be 400% faster, but maybe 10-20%. And initially there won't be any new ISA software, so all software will use the old ISA. Thus the new CPU will be much slower for "all" software (from the users perspective) because of the need for emulation. This causes the new CPU to be a bad deal for users, thus causing developers not to release software with the new ISA. This is probably an important reason why IA-64 failed, but x86-64 succeeded, Itanium CPU's ran x86 software at about half the speed for a much higher price. The ARM solution seems like the least suboptimal solution in this case, as it at least eventually allows support to be dropped, when emulation is no longer a problem. The only large-scale successful transition of an ISA migration without backwards compatibility is when Mac Os X transitioned from PPC to x86. It probably helped there that the Apple ecosystem is a bit special and much more closed and controlled, and that the Intel Core Duo's of the time had much better performance than the IBM G5's.
    - pcwalton 9y ago
      Relative to x86, a lot more ARM use cases are in the embedded space, where one vendor writes all the software that will ever run on the CPU. So I think there's merit to the idea that it's easier for ARM to break backwards compatibility than Intel can. Of course, a lot of ARM use cases also don't have that luxury. Android apps using the NDK are the most obvious example. The Raspberry Pi is another example: the RPi3 is still on 32-bit, held there by binary blob drivers and the massive amount of effort needed to create the fully open source driver stack that's a prerequisite for moving over (Eric Anholt is doing an incredible job; it just takes time).
    - sqeaky 9y ago
      Itanium also did it by slapping on another die that was an x86 cpu. The core Itanium instruction set where totally new and different at the time. If the new thing were and x86_64 CPU with just the oldest, least used and least useful features removed, things that haven't been used intentionally by new software in the past 15 years the problems you describe could largely be avoided. The gains would not be as big as cutting out the all worst features, but there would be some gains for minimal pain. Potentially this could be paired with a deprecation process that Intel, AMD and other x86 (Are there any other) manufacturers agree on in an open setting with ISVs. If this working group announces the deprecation of some features and the ISVs agree its a good idea, then the chip makers could put out a date some years in the future where that feature would no longer be in new CPUs.
    - nine_k 9y ago
      Do you remember how Apple Macs moved from Motorola 680x0 to PowerPC? And then to Intel? They had fat binaries and slow emulation as a stopgap solution. But these become mostly unused pretty soon. That is, there is a possibility to move to a new ISA if most of the software will be recompiled with minor changes, and there's plenty of will to upgrade. This could work for server software. Not so with Windows desktop software, of course. On the server side, one can use quite good Power8 servers right now, or ARM-based servers, depending on the workload. An Intel CPU with a non-x64 architecture might have a good chance against them. But the transition would be hard if Itanium or Transmeta are any indication.
- pcwalton 9y ago
  Sure they do: people want to keep playing Candy Crush when they buy a new phone.
  - perbu 9y ago
    Candy Crush is compiled to more or less architecture-independent bytecode on Android and a dual (32/64bit) binary on iOS. So no worries wrt Candy Crush.
    - bretthoerner 9y ago
      There's a lot more to CPUs than the size of their registers. The fact that those 32/64 bit binaries still run is exactly the kind of legacy support we're talking about.
  - fred256 9y ago
    iOS 11 coming out this fall won't support 32-bit apps.

mikepurvis 9y ago

ARM doesn't have to support legacy binaries in the same way that the wintel ecosystem does. I don't think it's really comparable.

runeks 9y ago
Is it really a problem to emulate this in software, though (honest question)? As far as I can see, if compability with old software is the only concern, then losing 80% performance isn't really a problem since the new CPU is probably 5x faster anyway. Thus making up for the loss, so the old executable runs as fast on a new CPU, using emulation, as it did running in hardware on the old one. So all we'd really lose is a speedup for legacy software -- and who really needs to play Wolfenstein 3D at 80,000 FPS, as long as it works?
- dtech 9y ago
  Yes, it is a problem. The new CPU won't be 400% faster, but maybe 10-20%. And initially there won't be any new ISA software, so all software will use the old ISA. Thus the new CPU will be much slower for "all" software (from the users perspective) because of the need for emulation. This causes the new CPU to be a bad deal for users, thus causing developers not to release software with the new ISA. This is probably an important reason why IA-64 failed, but x86-64 succeeded, Itanium CPU's ran x86 software at about half the speed for a much higher price. The ARM solution seems like the least suboptimal solution in this case, as it at least eventually allows support to be dropped, when emulation is no longer a problem. The only large-scale successful transition of an ISA migration without backwards compatibility is when Mac Os X transitioned from PPC to x86. It probably helped there that the Apple ecosystem is a bit special and much more closed and controlled, and that the Intel Core Duo's of the time had much better performance than the IBM G5's.
  - pcwalton 9y ago
    Relative to x86, a lot more ARM use cases are in the embedded space, where one vendor writes all the software that will ever run on the CPU. So I think there's merit to the idea that it's easier for ARM to break backwards compatibility than Intel can. Of course, a lot of ARM use cases also don't have that luxury. Android apps using the NDK are the most obvious example. The Raspberry Pi is another example: the RPi3 is still on 32-bit, held there by binary blob drivers and the massive amount of effort needed to create the fully open source driver stack that's a prerequisite for moving over (Eric Anholt is doing an incredible job; it just takes time).
  - sqeaky 9y ago
    Itanium also did it by slapping on another die that was an x86 cpu. The core Itanium instruction set where totally new and different at the time. If the new thing were and x86_64 CPU with just the oldest, least used and least useful features removed, things that haven't been used intentionally by new software in the past 15 years the problems you describe could largely be avoided. The gains would not be as big as cutting out the all worst features, but there would be some gains for minimal pain. Potentially this could be paired with a deprecation process that Intel, AMD and other x86 (Are there any other) manufacturers agree on in an open setting with ISVs. If this working group announces the deprecation of some features and the ISVs agree its a good idea, then the chip makers could put out a date some years in the future where that feature would no longer be in new CPUs.
  - nine_k 9y ago
    Do you remember how Apple Macs moved from Motorola 680x0 to PowerPC? And then to Intel? They had fat binaries and slow emulation as a stopgap solution. But these become mostly unused pretty soon. That is, there is a possibility to move to a new ISA if most of the software will be recompiled with minor changes, and there's plenty of will to upgrade. This could work for server software. Not so with Windows desktop software, of course. On the server side, one can use quite good Power8 servers right now, or ARM-based servers, depending on the workload. An Intel CPU with a non-x64 architecture might have a good chance against them. But the transition would be hard if Itanium or Transmeta are any indication.
pcwalton 9y ago
Sure they do: people want to keep playing Candy Crush when they buy a new phone.
- perbu 9y ago
  Candy Crush is compiled to more or less architecture-independent bytecode on Android and a dual (32/64bit) binary on iOS. So no worries wrt Candy Crush.
  - bretthoerner 9y ago
    There's a lot more to CPUs than the size of their registers. The fact that those 32/64 bit binaries still run is exactly the kind of legacy support we're talking about.
- fred256 9y ago
  iOS 11 coming out this fall won't support 32-bit apps.