knowitall

Dave1960 said:

Not a smart move. 

Already run into compatibility issues with Windows tablets not able to print from ARM CPU's. 

Not enough printers support ARM drivers yet, although this could possibly spur manufacturers to build ARM drivers for their machines. 

Still this won't happen for older devices - they won't put the resources into it. 

elijahg said:

knowitall said:

elijahg said:

A significant factor in the PPC > x86 switch was Rosetta. It is much easier to emulate RISC PPC with its relatively small instruction set than it is CISC x86, and now x64. PPC apps running in Rosetta weren't much slower than the native ones, but that was also partly offset by the Intel CPUs being much, much faster than PPC ones. The A-series CPUs are quick, and in a less power and thermally constrained environment no doubt even quicker - but CISC emulation on RISC architectures is excruciatingly slow, no matter how fast the native CPU. Remember Connectix's Virtual PC? That emulated an x86 machine on PPC. Installing Win98 took 3 or 4 hours even on a G5. Of course API level emulation a-la Rosetta has less overhead, but it's still slow. 

Also, people who are switching to Mac can still use the Mac as a PC if they need to. It provides a comfort blanket. As soon as Apple switched to x86, Mac sales took off.

I wouldn't call running Windows comfortable, not even in another universe.
Its best to get rid of it.
Running ppc apps under Rosetta was slow, very slow and some apps didn't run at all.
Running CISC on RISC or vise versa isn't inherently more difficult. It isn't guaranteed to be symmetrical but that doesn't depend on CISC or RISC (this is nowadays an outdated distinction) or the number of instructions one or the other has.
I would say that a 64 bit instruction set (or not) is a more important notion when translating instruction sets. The internal state of the processor and how easily it is represented on another (processor) is also an important notion.      
I would expect to see a difference in efficiency even per instruction.
All in all I expect that on average only a few instructions are needed to translate one instruction set to another no matter what.
Current processors are extremely fast so a factor 5 or so will not be noticed when running most apps.

Edit: one fun fact to consider is that Intel already hardware translates its (CISC) instruction set(s) on its internal RISC instruction set at full clock speed, so its certain that this isn't a slow option. 

But people have to use Windows to get work done on programs that aren't available on macOS. So you just say to all those who may rely on those programs for a living "sorry mate, you're out of luck. Goodbye"? 

Rosetta wasn't great, but it wasn't particularly slow. Almost everything worked. Do you think then, Apple shouldn't bother with a compatibility layer if x86 > ARM happens, and just again, tell everyone who relies on some x86-only programs for a living that it's too bad, we're moving on and don't care?

RISC and CISC are still relevant when talking about processor emulation.

"All in all I expect that on average only a few instructions are needed to translate one instruction set to another no matter what." Not that simple. Even if it was on average 5 native instructions per emulated instruction it would still be a huge performance hit. And as I said, it's more difficult to emulate the massive CISC x64 instruction set than it was the relatively concise RISC PPC one. There's also the endianness issue, which means every byte has to be flipped. 

"one fun fact to consider is that Intel already hardware translates its (CISC) instruction set(s) on its internal RISC instruction set at full clock speed, so its certain that this isn't a slow option. " 

That's because it runs at native speed in hardware. It's not software emulation. It still is at least one extra pipeline stage too.

stevewhitemd said:

Mr. Dilger's article almost makes me feel sorry for Intel. Almost. What's interesting about Intel isn't that they failed to recognize the corner they'd painted themselves into with the x86 architecture -- it's that they DID recognize, and tried to solve it, and failed. They tried to get into other chip fabrications like broadband, and failed. They tried IA-64, and failed. They tried the Atom, and failed. For broadband and Atom it became clear to the industry that Intel's solution wasn't good enough, but for IA-64 and Itanium Intel fell into the classic trap of having a superior product that others wouldn't invest in to use. Microsoft wasn't going for it and neither were the other industry leaders. You'd think that someone at Intel would learn from all this failure -- Apple (well, really, Jobs, and to a fair extent Cook and Ive) certainly learned from failure, which is why we got the iMac, iPod, iPhone, Mac OS X, etc. Failure, if you survive it, is a good teacher. What has Intel learned? Darned if I know.

macplusplus said:

knowitall said:

elijahg said:

A significant factor in the PPC > x86 switch was Rosetta. It is much easier to emulate RISC PPC with its relatively small instruction set than it is CISC x86, and now x64. PPC apps running in Rosetta weren't much slower than the native ones, but that was also partly offset by the Intel CPUs being much, much faster than PPC ones. The A-series CPUs are quick, and in a less power and thermally constrained environment no doubt even quicker - but CISC emulation on RISC architectures is excruciatingly slow, no matter how fast the native CPU. Remember Connectix's Virtual PC? That emulated an x86 machine on PPC. Installing Win98 took 3 or 4 hours even on a G5. Of course API level emulation a-la Rosetta has less overhead, but it's still slow. 

Also, people who are switching to Mac can still use the Mac as a PC if they need to. It provides a comfort blanket. As soon as Apple switched to x86, Mac sales took off.

I wouldn't call running Windows comfortable, not even in another universe.
Its best to get rid of it.
Running ppc apps under Rosetta was slow, very slow and some apps didn't run at all.
Running CISC on RISC or vise versa isn't inherently more difficult. It isn't guaranteed to be symmetrical but that doesn't depend on CISC or RISC (this is nowadays an outdated distinction) or the number of instructions one or the other has.
I would say that a 64 bit instruction set (or not) is a more important notion when translating instruction sets. The internal state of the processor and how easily it is represented on another (processor) is also an important notion.      
I would expect to see a difference in efficiency even per instruction.
All in all I expect that on average only a few instructions are needed to translate one instruction set to another no matter what.
Current processors are extremely fast so a factor 5 or so will not be noticed when running most apps.

If it was so easy why Microsoft has failed with Surface RT? Why desktop Windows applications didn’t run on RT?