AMD: Windows-8-on-ARM app compatibility is relative

Porting...

Of course stuff should "port" just fine. The real issue is whether or not the relevant software vendors will bother with that process. It's really not an issue of how feasable it is but whether or not the vast majority of publishers will ever bother.

You are missing the point

The power of ARM is in the offload.

Arm SOCs have offloads for anything and everything - media, network, security, encoding, decoding, etc.

These have been designed _WITHOUT_ a common software architecture in mind. There is no way in hell to abstract them to a common API which high level programs designed for Windows can use. It is a throughly balkanized platform and this is the reason for it being so popular - you can create whatever obscenity you want to satisfy reqs from business development.

That may not matter for things like Word which need little or no offload, but it will be a serious hindrance for the biggest market driver in the windows world - Games.

In any case, whatever AMD, Intel, etc are speaking here is irrelevant as they are not the ones who are facing the exact part which makes ARM a throughly balkanized platfrom. It will be more interesting what people like Carmack, Romero and the like say about it. They are the ones that are actually facing what makes ARM powerful and nightmare at the same time. They are funnily enough strangely silent on the matter...

... and therein's the rub!

NEAR NATIVE SPEEDS. That translates to significantly less.

Glad you said it, but insanely wrong

Let me respond to each item .

1) FX!32 was utter trash, it didn't work very well at all and that's possibly the #1 reason why people chose far less capable processors from Intel than to buy Alphas. Additionally, the fact that smaller developers couldn't afford Alpha's to develop on pretty much killed the platform. On top of that, development of applications for Alpha required the Visual C++ 4.0 subscription model which cost substantially more than a copy of Visual C++. This completely eliminated the possibility of mom an pop vendors slapping together a blind port of their software hoping it would work.

2) Transmeta's processors were entirely different than this circumstance. Think of them as running an entire emulated system from the very start. Their code recompiler started during boot and ran translated all code to the new architecture. This would be more similar to running QEMU as opposed to providing an application compatibility layer. This is a SUBSTANTIALLY EASIER TASK than to make an app for one processor run on the OS of another processor. Apple managed to do it using Rosetta Stone and still had tons of problems with compatibility, but by including the PPC system libraries with the x86 OS as well made it much easier. It also allowed Apple to manually code some of the more difficult thunks.

3) The X-Box emulator on the X-Box 360 is more similar to a full system emulator than it is to an app emulator. It is still difficult as hell and the little-endian to big-endian conversions still take massive amounts of the XBox 360 system's capabilities, but the fact is, this is still a full system emulator. There is an entire copy of the x86 system software with many hand coded thunks (possibly a tremendous amount due to the possibility to automate much of it) to make this emulation smoother. There were still problems with the emulation anyway, but Microsoft did do a great job of it anyway. However performing full dynamic recompilation of an entire system when the host system is a speed demon in relation to the emulated system is trivial in comparison to developing a subsystem.

There are some issues involved with making x86 work on ARM which should be addressed.

1) ARM is the same endian as x86 which allows high end dynamic recompiler optimizations to be performed. In fact, it is entirely possible to treat an x86 executable or DLL as a source code listing and recompile the file to ARM without needing dynamic recompiling in many cases. This will be a total flop in the cases of hand coded instruction level parallelization code (or code generated from the Intel compiler for SSE). But endian conversion is the #1 limiting factor when emulating another system.

2) ARM handles unaligned memory access far worse than Intel does. Hell, x86 is the only processor that doesn't suck on a biblical scale at this task. It has to do with Intel always trying to run 8, 16 and 32-bit code faster than the previous generation. So they designed their cache subsystems and prefetches to handle this beautifully. Sadly, the ARM really sucks big old ding dong on this task. But if you have code written for and tested on ARM, this isn't an issue. However when emulating an x86 on an ARM, it will be necessary to handle this gracefully or performance will suffer terribly.

3) Code compiled for instruction level parallelization will not function properly using dynamic recompilation. The parallelization will most likely need to be unrolled (similar to unrolling loops) which can cause chains of instructions to be as many as 16 times more instructions per task than otherwise. NEON does not map even remotely close to SIMD. IMNSHO, NEON is often more similar to the less complex Altivec instructions than to SIMD and therefore dynamic recompilation would require that the recompiler is a long instruction chain auto-parallelizing compiler for it to not destroy performance completely. The good news is, auto-vectorizing code which was previously vectorized is not too hard in comparison to autovectorizing code which otherwise was linear in its nature.

So, there's an option here. Unlike in the says of FX!32 which as I mentioned earlier sucked... as does the x86 emulation on Itanium, Microsoft shipped Windows 7 with a full copy of Windows XP in a virtual machine. This design allowed applications that ran better on Windows XP to run, almost fully integrated with the desktop using RemoteApp via RemoteDesktop on the virtual machine. Using the same technology, it would be possible to install Windows XP or Windows 7 on an emulated virtual machine and integrate the same way. Performance will still be utter rubbish compared to an app running natively and applications like video players will be awful, games will suck BADLY, but pretty much all applications will run nicely this way.

Now this brings us to the last issue.

Developer seeding.

I'm not going to write the same bloody application for two architectures. I'm not going to carry around two laptop computers so I can hand optimize my code on both chips before releasing anything. Therefore, NVidia or whoever decides to emulate and x86 to allow legacy apps for x86 to run on ARM better also provide a similar ARM emulator for x86 laptops. The laptop I'm coding on right now (though I'm writing this while I download something) is a Core i7 with 16 gigs of RAM and a GeForce GT540M. I would be in shock if I see anything that comes close in performance to this machine in the ARM world for a while to come. I buy a new development laptop once a year and try to nearly double performance over the previous one if possible each time. So, until the ARM guys put out a competitive development computer, I'll need some way of coding for ARM if I'm going to write anything for ARM. I do not code .NET, I write native code and often count clocks. .NET apps are nifty for the surrounding applications, but when it comes to video codecs, video filters, etc... those have to be coded in native code.

So, while you made some interesting remarks regarding what you though you knew about emulation, you were REALLY far off.

Now for the zillionth time...

Emulation of x86 binaries work on something like Alpha only because at the time the Alpha architecture was MUCH BETTER than what it was emulating. Typically, there is always a huge performance hit for emulation. If you have enough extra capacity/performance then this is not a problem.

This is why Alpha emulation of x86 binaries worked and why stuff like vmware works somewhat.

ARM is on the other side of the equation. So "emulation" will likely be painful and unpleasant.

Point: Missed!

x86/x64 is great for desktop systems, the sort of high power big box workstations that will run content creation software that requires hefty resources. It sucks for the sort of small, low power, easily portable devices that content *consumers* are more interested in. Who the hell wants to run an IDE or a CAD package on a pocketable tablet?

This single-entity 'industry' you're grumbling about doesn't exist. And even if it were to pop into existence, it wouldn't care. You seem to be searching for some sort of 'WinARM' conspiracy here. There isn't one.

As for hosing consumers, that's a little tricker. Most people use remarkably few bits of software, and the bits of software they do use are generally under current or recent development, pretty far from the sort of legacy software that is at risk here. If you want to continue running all your old crap, feel free to keep running it on your desktop. MS can't afford to simply abandon intel/amd; the platform will be around for years.

Like sentence fragments much?

"How many x86 developers recompiled their code to be PC and APPLE compatable?"

Autodesk for example does this in their new applications. They're developing now using Qt which allows them to easily compile for both platforms.

You pooch screwed with technical gibberish better than I ever have in the past. I wonder if in person you are able to assembler coherent thoughts with greater depth. BUT....

You don't compile an app for Windows and Mac (PC apps run just fine on APPLE btw if you boot to Windows on it). You PORT and application to run on Windows and Mac OS X. It requires developing a great deal of new code to support the new user interface and system libraries. Developing cross platform code has become a great deal easier over time, but in reality, the differences between GCC (and LLVM) and Microsoft Visual C++ are substantial. System headers have nearly nothing in common. Code accessing the network is a mess especially when you consider that the BSD sockets library and the Windows Sockets library are similar but not directly compatible. The UI has absolutely nothing in common.

On the other hand, your comparison would make more sense if you asked "How many Mac PowerPC developers compiled their code for x86 when the tools came out?" the answer would be about 90% and 99% of them did it successfully and the same happened in the reverse direction.

Recompiling code isn't the problem. The problem is chip level optimizations. The problem is architecture specific profiling. The problem is memory alignment. And a few others. The fact is, most applications will port quite easily between platforms. But just because the code has been ported doesn't mean it will perform well.

AutoCad will probably run pretty well through emulation. Also, it uses almost no chip specific code. It doesn't need it. If Autodesk judges there will be a market for Autocad on Windows ARM, I'm sure they'll port it to the new platform. But, NVidia and the others will have to prove there is a market base for it.

I'm a bit amazed that NVidia isn't trying to see developer systems to developers to start getting code ported.

The thousands of legacy titles you're referring to in your posting may not be an issue. Most of those thousands of titles most likely are not processor intensive application anyway. Running them in an emulated virtual machine (QEMU style) and integrating them with the desktop similar to how Microsoft does with the XP emulation for Windows 7 through virtual PC will be just fine. With a decent set of drivers for the guest OS, it might even be good enough for autocad.