3 ms·

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 IS

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

by dtech 9y ago

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.