hattig

"In the PPC processor days of the Mac the PPC processor had some Intel code in it. "

Whoa, whoa, what? That is absolutely not true. Actually, most of that is completely irrelevant or incorrect or just so confusing it shows the writer doesn't understand fully despite reading lots of different things.

"there is currently no way to get a DirectX game to work on iOS devices"

Games for Mac and iOS use OpenGL (or newer ones will use Metal if you're lucky and Metal has the features they need). "All" that is required is a recompile of the game sources (typically C++) for ARM. macOS already supports fat binaries - historically for a selection from PowerPC 32-bit, PowerPC 64-bit, Intel 32-bit, Intel 64-bit - but now they're just using Intel 64-bit. Adding ARM 64-bit here isn't an issue, not after the initial port from Windows+DX to macOS+OGL/Metal.

VirtualPC was slow because it was emulating x86 instructions on a PowerPC processor - and that was in the days before JIT transpilation. Virtualisation is different, that's running multiple systems transparently on the same system. Nobody will run x86 games on ARM, they will run native games on ARM. Porting the app to ARM (once you've ported it from Windows to macOS) will likely be a configuration setting.

Note that x86 Android devices do include an ARM emulator for ARM apps, and it's very clever and it transpiles and everything so that it gets pretty good performance. It is likely that IF apple did an ARM macOS device, they would include an x86 emulator that did all that stuff but in the opposite direction.

Apple aren't going to be telling the IT department at Best Buy or anywhere else the technical specifications of unannounced products. So at best it's a guessed-at placeholder, probably using previous details but changed enough to be unique.

Modern foundry processes are mostly marketing names, not exact matches to transistor size.

For example, TSMC's 16FF is actually a 20nm BEOL, with Finfets underneath, at the density of 20nm. Hence TSMC's A9 was larger than Samsung's.

Not that Samsung's 14nm was 14nm, it was closer to 18nm.

But before you think Intel are blameless, their 22nm was closer to 26nm, and their 14nm is closer to 16nm at best. And Intel's SRAM is dense, but their other logic less so, hence why some 28nm chips sometimes appear to have transistor densities close to Intel still.

So you can see where we are going here with the "10nm" processes. TSMC's is more like a real 14nm process - denser than Intel's 14nm, but as I wrote, that was more like 16nm really.

But regardless, it's smaller, and this 10nm process is at least a proper shrink at last over the previous process.

Let's not start talking about GlobalFoundries' 7nm process... http://semiaccurate.com/2016/09/26/globalfoundries-7nm-process-isnt-even-close-name/

I think this has been clear since they said that Windows 8 would run on ARM processors, and have the option of a Windows Phone 7-esque front-end.



Of course it is a mistake and error for them to be making. It paints Windows Phone 7 as a dead-end operating system for one, even though in reality it's tablet/touch features will migrate to Windows 8 just like iOS features are entering Mac OS X.



Also Windows 8 on a tablet might be fine, but legacy apps will remain a complete pain to interact with in tablet mode, nevermind Flash, etc, which don't understand touch vs mouse pointer.



Windows 8 tablets will therefore be doomed to be dual-mode devices. Dock them, and they behave like a slow desktop PC. Undock them and they behave like rather bit bloated tablet. At least the same data will be available to both front-ends, and I presume that Office will provide a tablet UI as well as a desktop UI... it will, won't it? I mean, iWork has done that for a year...