chrishoffman at January 22nd, 2014 06:40 — #1
Originally published at: http://www.howtogeek.com/180225/arm-vs.-intel-what-it-means-for-windows-chromebook-and-android-software-compatibility/
Intel x86 or x64 processors have traditionally been found in laptops and desktops, while ARM processors have been found in lower-power embedded devices, smartphones, and tablets. But you can now buy laptops with ARM chips and smartphones with Intel chips.
localhost at January 22nd, 2014 11:00 — #2
I cant wait for the day when my phone/tablet is powered by a CISC Intel CPU. I want to leave ARM and all its RISC brethren in the past... where they belong.
Baytrail is the way forward... I hope.
wilsontp at January 22nd, 2014 11:22 — #3
bah. CISC is a waste of resources, and ARM is more energy efficient.
I want to see things go the other way, with desktop operating systems supporting ARM and getting off of the x86 instruction set with its unnecessary complexity.
wilsontp at January 22nd, 2014 11:26 — #4
Also, x64 is not the correct name for 64-bit architecture, as much as Intel would like it to be.
The correct name is AMD64, since the current 64-bit architecture was invented by AMD, and not Intel.
Prior to launch, "x86-64" and "x86_64" were used to refer to the instruction set. Upon release, AMD named it AMD64. Intel initially used the names IA-32e and EM64T before finally settling on Intel 64 for their implementation. Some in the industry, including Apple, use x86-64 and x86_64, while others, notably Sun Microsystems7 and Microsoft, use x64 while the BSD family of OSs and several Linux distributions use AMD64.
localhost at January 22nd, 2014 12:28 — #5
While I agree that x86 isn't the most efficient architecture, its far too limited for anything other than mobile devices.
Its the reason why a proper Windows 8 tablet is far more appealing to me than an Android based one just based on the ecosystem. It wasn't feasible on an x86 CPU because of the power consumption, but these new Baytrail CPUs are achieving near ARM level of power consumption - 6-7W under full load including the GPU. Thats perfect for a tablet and comes with the advantage that the entire x86 library of programs (albeit slowly on some). We might be a year or so away from a x86 CPU suitable for phones though.
costeakai at January 23rd, 2014 02:04 — #6
The author talks about "recompiling" but the billions & billions of x86 enterprise software, that matters, needs more than a simple recompilation. That's why the enterprise software for the arm ecosystem needs to be done from zero up. I have, some time ago, accepted the very evident ideea, that it's far better not to recompile, not to change ANYTHYNG at all ! So cherrytrail, and the likes, with minimum power consumption and maximum multicore performance, and sata-express and ddr4 compatibility are the way forward. I just hope that amd will keep up with intel. I believe that arm, mostly because of the need to re-create tho whole enterprise software stack from scratch, is doomed. Well, if esri, autocad, adobe and the likes will redesign their essential software for arm64, things might change. These days you can hear whispbers of google thinking about designing its own arm processors; but even google will have to redesign its whole software stack (think of all those x86 search algorithms) from ground up.
nsdcars5 at January 23rd, 2014 05:37 — #7
x86 looks much more feasible for the future. It's got more power, but the electric consumption is coming down. Sure, ARM is increasing power-wise, but x86 is much more flexible in the way that many more operating systems are designed for it, making it simpler to port stuff, from say, the Modern UI to Android (or the other way round).
wilsontp at January 23rd, 2014 11:58 — #8
The only time you really care about the CPU architecture is when you're writing in assembly language. For the most part, when you're writing in C++ or any other modern language, you don't need to know what CPU you're writing for. (The exception has to with things like byte packing and integer size, but those can be addressed as-needed.)
If the OS has the same API's, then it's mostly a matter of clicking "Build" with the compiler's output set to the right CPU. There are often subtle differences in the OS caused by the requirements of different architectures, but those are porting issues, not "starting from the ground up" issues.
Ask all the Apple developers how hard it was to switch from PowerPC to Intel. I'm pretty sure they'll tell you they didn't have to rebuild their application from the ground up.
Austin Meyer builds X-Plane, a flight simulator (possibly the most intensive, power hungry application you can run on a PC), for PC, Linux, and Mac. He does have to do some porting to bring Mac code to the PC, but it's hardly "from the ground up."
Yes, ARM uses a very different machine language than x86, but when you get to the C++ level, you don't know or care what CPU you're running on... and if you're running a bytecode language like C#, you care even less, since the CLI or Java VM takes care of it.
If Microsoft did release a full-blown desktop OS for ARM Windows, you can be certain that they would design in all the API's we're used to, just like they did for PowerPC and Itanium architectures. Heck, even native 64-bit programs require recompliation. It's really not that hard.
Do you have to rebuild your programs from scratch for Metro apps? Yes. But that's because Metro is a whole new set of API's. That has nothing to do with ARM.
localhost at January 23rd, 2014 14:48 — #9
If Microsoft opens up their Surface RT devices to allow third party software to run as they would in a traditional Windows computer, I'm all for that.
Recompiling a few programs so that they'll run on ARM is fine by me. What's not fine is being locked down to whatever Microsoft thinks I'm allowed to run. I can manage my own systems TYVM.
costeakai at January 23rd, 2014 15:15 — #10
i can see there's android.open.office, openoffice ported for android. but i still think that microsoft did more than recompile x86 windows in order to get windows rt. when you're dealing with a big software stack, you have to redesign the whole stack when changing the run environment. you might just recompile some little subroutines, or most subroutines, if they are really modular and independent. but when you recombine the subroutines to create a different final software stack, you must create new combinations. why didn't microsoft renewed the whole dotnet software stack when they moved to dotnet 4.5? because there was too much to be done. so they wrote the dotnet core, and left , for example ssms to use the old 3.5 dotnet. the subroutines aren't modular and independent, so you end up with 3.5 along side 4.5. is esri able to just recompile arcgis for arm, and voila , arcgis for android? no, first there must be all the dotnet redesigned for arm or x86 android, and i'm afraid quite a few windows apis redesigned also for android, and then maybe esri will be able to recompile. but i think that esri and autocad are already redesigning for android. even ms did some office for android. my believe is that intel will offer a better environment than arm for big software stacks porting from windows to android.
wilsontp at January 27th, 2014 18:20 — #11
No you don't.
You only have to re-design stuff that's specifically affected by your hardware change: that's the whole point of modular hardware.
For example, you'll probably need device drivers for the display and the digitizer. You'll certainly no doubt need device drivers for the chipset. You'll certainly need a new compiler, since ARM machine language is different than x86 and AMD64 machine language.
But you don't need to re-write applications. You don't even need to re-write your API's. You just need to replace the low level software the directly interfaces with the hardware, including device drivers and the HAL. That's the whole point of the HAL, actually, to provide a boundary layer between the hardware and the software.
Do all applications work 100% when you shift architectures? No. Look at the shift to AMD64: some applications do have their problems. We had similar issues when we went from 16-bit to 32-bit Windows. However, most applications upconvert with little or no trouble, and recompiling for a new architecture is often just a matter of flipping a switch and clicking "Build."
And let's not forget WOW. Microsoft has made an art form of running software for different architectures on the same machine at the same time. Since all CISC instructions can be boiled down to one or more RISC instructions, it's theoretically possible to actually run x86 programs on a RISC processor without the need for traditional virtualization.
Finally, as I already said, look at the amount of bytecode-compiled languages out there now. More and more programming is shifting toward languages like .Net, which makes architectural transitions even easier: I can run a pure .Net assembly on a Mac or Linux box, often with zero changes. (It depends on whether the programmers did things in a portable fashion, but that's another convo.)
In short, an architecture change doesn't have to mean a re-write of applications, but it does mean a re-write of significant portions of the operating system.
raphoenix at January 27th, 2014 19:42 — #12
costeakai at January 28th, 2014 13:10 — #13
summary: winRT has a small number of operating system APIs, similar to android; windows x86/64 has a huge ammount of old & new op.sys-apis; if you create software for a weak cpu, such as arm, you make an android apk or winRT app, the 'new-restricted-way'; if creating for a stronger cpu, like baytrail, kaveri, core-ix, you are less restricted, and you may be programming the old-careless-way; winRT only accepts new apps, that's why the whole office had to make use of the winrt apis ONLY, and that's why none of the other windows x86 software can not be recompiled to be able to run on winrt. it all has to be rewritten in order to only use winrt apis. on the other hand, android apis will have to bifurcate for x86 and arm. and android apis for x86 will be better. i hope i am making myself undersood.
wilsontp at January 28th, 2014 14:15 — #14
You're making yourself understood. You're just not dealing with all the facts.
If Microsoft was to create a full-blown Windows desktop for ARM, it would not be Windows RT. It would be Windows with an ARM RISC Hardware Abstraction layer.
In fact, Windows NT used to run on several different proccessors, not just x86-derived CPU's. It ran on MPS and Alpha CPU's, and there is an Itanium version of Windows Server. (Itanium is a different 64-bit architecture that is incompatible with the AMD64 standard.)
Originally, Windows NT was developed on RISC computers. The whole idea behind Windows NT was to get off of x86 processors. Microsoft's plan was to move to RISC platforms, at least for their servers. Windows NT ran on MIPS, DEC Alpha, and Power PC CPU's.
Guess what ARM processors are? They are RISC processors. I doubt they use the ARC instruction set that went in to MIPS and Alpha, but that's mostly a compiler issue.
So based on the history of Microsoft's Windows NT line of operating systems, there is absolutely no reason to suspect that porting well written apps to ARM would be any great difficulty.
system at February 1st, 2014 06:40 — #15
This topic was automatically closed after 10 days. New replies are no longer allowed.