Intel: Windows on ARM Won't Run 'Legacy Apps'

Page 2 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Status
Not open for further replies.

enforcer22

Distinguished
Sep 10, 2006
1,692
0
19,790
[citation][nom]molo9000[/nom]Try explaining to a consumer why he can't install the same programs on his desktop and his tablet even though both run Windows 8....[/citation]

If the customer is to damn stupid to realize this before hand they shouldn't buy it. Why should it work on a tablet if it works on a pc. A pc has a lot faster and more capable hardware. It could work the other way around if it works on the ARM version it could work on the PC version but until tablets get some power the customer is fooling him self if thats gunna happen. Perhaps some office software with two versions on the install disk maybe. Emulation is easy if you got the horse power. Tablets are basically garbage in that area. So from tablet to PC sure from pc to tablet almost never.
 

back_by_demand

Splendid
BANNED
Jul 16, 2009
4,821
0
22,780
I guess if I want to still use my old Photoshop or various games, etc, i'll just have to use an Intel or AMD CPU, damn, I will be forced to use a chip that has many more times the horsepower.

Until ARM gives massive performance they won't be clawing any of the desktop market away from Intel anytime soon.

As far as mobile devices go, give it time, Intel will create a chip that goes in a tablet and is as power efficient.

Patience young Skywalker...
 

burn-e86

Distinguished
Jul 25, 2006
396
0
18,780
[citation][nom]EnFoRceR22[/nom]If the customer is to damn stupid to realize this before hand they shouldn't buy it. Why should it work on a tablet if it works on a pc. A pc has a lot faster and more capable hardware. It could work the other way around if it works on the ARM version it could work on the PC version but until tablets get some power the customer is fooling him self if thats gunna happen. Perhaps some office software with two versions on the install disk maybe. Emulation is easy if you got the horse power. Tablets are basically garbage in that area. So from tablet to PC sure from pc to tablet almost never.[/citation]

You mean the customer who buys a piece of software for windows 8 tablet, and doesn't realise it's for windows 8? yea, wheres the confusion there?
Or the same customer who bought a piece of software that ran fine on windows XP Pro, XP Home, XP MCE, XP Starter, XP 64. then bought a different software and ran it on Windows Vista Starter, Home, Home Premium, business, ultimate, 64-bit home, 64-bit Home premium, 64-bit business, 64-bit ultimate. etc.
Point is, if they see windows 8, they'd expect it to work across the range, not just on a single version (64-bit software not withstanding...)
 
G

Guest

Guest
In other words, no Intel chip with the TPD of an ARM chip. Intel R&D, y u no deliver Atom using x100 less power?
 

socalboomer

Distinguished
Sep 13, 2008
90
0
18,630
[citation][nom]socalboomer[/nom]Anyone notice that nobody from Microsoft is quoted here - only from Intel. . .who stands to profit if people stay away from any ARM based Windows installs. . .Not saying she's wrong, but I would prefer to hear from Microsoft on this matter, not Intel.[/citation]

And, from Ars, Microsoft responded and Intel is full of crap!

Redmond seems more than a little displeased at the comments made by Otellini and James. An unusually strongly-worded statement issued by the company reads:

Intel's statements during yesterday's Intel Investor Meeting about Microsoft's plans for the next version of Windows were factually inaccurate and unfortunately misleading. From the first demonstrations of Windows on SoC, we have been clear about our goals and have emphasized that we are at the technology demonstration stage. As such, we have no further details or information at this time.

Nice, Intel. . . Nice FUD
 

socalboomer

Distinguished
Sep 13, 2008
90
0
18,630
[citation][nom]schmich[/nom]I might be wrong on this but logically I think I'm not (if I am please correct me). Legally, an emulation software would most likely require an x86 license from Intel. Having an x86 emulation for ARM to run legacy apps would be AGAINST Intel's interest. So Intel would is not going to 1) make an emulator 2) license it to eg. Microsoft to make one.This is quite unfortunate since one of the main reasons for Win 8 on ARM would have been the ability to run all the applications. However you can understand Intel's decision.Considering people have managed to emulate complicated consoles such as the PS2 maybe we'll see illegal x86 emulators for Win 8 ARM.[/citation]

You're wrong in the sense that no emulator is needed if Windows is compiled for ARM and then programs run within Windows. There's no emulator needed. That's the point with compiling Windows for the different processor.

You may not remember "back in the day" but I had Windows running on several architectures and nearly everything ran just fine on all of it. I only say nearly because my memory isn't perfect so . . . :D

That's really the point. Programs don't run on the hardware; they run within the OS which itself abstracts to the hardware.

Which is why BOTH Windows and MacOS (and Linux) run on Intel. And then the programs, themselves, run within the OS's. Programs typically don't care what hardware is there - they make calls to the OS API's. They don't really care too much if it's nVidia or AMD/ATI. . . they just make calls to OpenGL or DirectX or whatever. . . they don't care if it's which chipset it is. . . they let the OS take care of that.
 
[citation][nom]socalboomer[/nom]Anyone notice that nobody from Microsoft is quoted here - only from Intel. . .who stands to profit if people stay away from any ARM based Windows installs. . .Not saying she's wrong, but I would prefer to hear from Microsoft on this matter, not Intel.[/citation]

Well its 100% true. ARM does not hold a x86 license and their CPUs are not capable of running x86 based applications, only Intel or AMD CPUs can.

ARM will be fine for the mobile market but I don't see it being utilized for DT.
 
[citation][nom]socalboomer[/nom]Programs don't run on the hardware; they run within the OS which itself abstracts to the hardware.Which is why BOTH Windows and MacOS (and Linux) run on Intel. And then the programs, themselves, run within the OS's. Programs typically don't care what hardware is there - they make calls to the OS API's. They don't really care too much if it's nVidia or AMD/ATI. . . they just make calls to OpenGL or DirectX or whatever. . . they don't care if it's which chipset it is. . . they let the OS take care of that.[/citation]

A program written in Java or C# may work on an ARM CPU, if somebody (Oracle, Microsoft) writes a JVM or .Net Framework for ARM. Even then, that program will fail if the developers inserted native calls (C++, C, assembly language, etc.) to improve speed in certain areas.

A program written in PHP or Python or Perl or other such languages will most likely work all right, if an interpreter written for ARM architectures and that language is available.

A program written in C++ or C or assembly language, on the other hand, will not even start if the CPU is not Intel or AMD. It contains native code that makes absolutely no sense to an ARM CPU. Even if the ARM CPU could understand somehow that 0x25A3FF21 (or whatever) means "increment the EAX register", that ARM CPU won't have an EAX register. You'd need an emulator.
 
[citation][nom]captaincharisma[/nom]so does this mean i can't run my 30 year copy of lotus 1-2-3? ")[/citation]
A DOS emulator based on QEMU will be trivial!

EDIT: Drat! Quoted the wrong one from the story page, but it still fits...
 

liveonc

Distinguished
Mar 24, 2008
437
0
18,780
32bit & 64bit software didn't scare anyone, & they were also running Windows. Even if Windows doesn't offer x86 support, someone will. If Intel wants to be more power efficient, maybe ARM wants to be more power hungry, & Nvidia still wants to sell Tegra...
 



Pretty much, anything compiled to binary will not natively run on a different architecture without emulation. That being said, AMD hasn't made an "x86" CPU in a very long time. Instead they build their own RISC style CPU descended from the Alpha with a front end x86 instruction decoder and branch prediction unit. The CISC x86 instructions are interpreted and broken into smaller RISC style instructions that are then dispatched to the various CPU resources for computation. All AMD would have to do is license the ARM ISA and design in a front end instruction decoder for ARM. It would have to be done as a co-processor so that the main system would be executing (booting and system loading) on x86 but a core could enter "ARM Mode" to execute ARM instructions.

It would be slightly more expensive then current CPU's and would have a performance penalty, but it is doable. Gotta love HW abstraction.
 

nottheking

Distinguished
Jan 5, 2006
1,456
0
19,310
The first two things that struck me when I read this article:

1. switching processor architectures obviously breaks compatability. This is a kind of "duh" situation. They use entirely different instruction sets, so anyone who understands enough about programs would know that a binary assembled/compiled to run on one instruction set obviously would be incompatible when running for a different instruction set, since each "instruction word" could mean something entirely different.

2. The only comments here are from Intel, which has a vested interest in holding onto x86's PC monopoly, and increasing its (currently very minor) market share in mobile devices. (versus ARM's near-monopoly)

Furthermore, it's an outright lie for anyone educated to claim that "ARM Windows 8 will never run legacy applications." There *is* such a thing as emulation, after all. It's what lets an Xbox 360 (using PowerPC architecture) run Xbox games. (which are x86) The fact is, there are ALREADY software emulators that can run x86 code on ARM CPUs. Sure, 100% drop-in backwards compatibility won't be achieved, but it certainly proves Intel's claim wrong.
 

nottheking

Distinguished
Jan 5, 2006
1,456
0
19,310
[citation][nom]palladin9479[/nom]Instead they build their own RISC style CPU descended from the Alpha with a front end x86 instruction decoder and branch prediction unit.[/citation]
"RISC-Style" is really kinda vague and dangerous of a term to use... After all, it can be quite argued that the P6 and later generations of Intel processors are non-x86 RISC as well with a CISC-style x86 front end decoder... Those words more or less describe the decoder system Intel first implemented in the Pentium Pro: break up instructions into μops, and pipeline them for maximum instruction throughput.

That's more or less the epitome of RISC, and in today's world memory (including cache and register, let alone main memory) has capacities that have effectively eliminated the need for extreme code density that was the whole goal of CISC designs.

So not only do we have all this abstraction in hardware you mention, it's blurring our lines, too. RISC vs. CISC isn't so clearcut... 'course, it really wasn't quite clear-cut in the first place, if you'd look at debates over the 6502...
 
When I say "RISC style" I'm refering to micro-ops single pass instructions vs the macro-ops multi pass instructions of a CISC ISA.

Intel's (PPro / P3 / C2) are very much a CISC cpu, or rather their more CISC-y with some RISC micro-ops thrown in. It really gets blurry but it definitely executes macro-ops (some get broke down into mini-ops).

AMD is definitely in the RISC camp. When DEC Alpha as going belly up AMD hired almost their entire Alpha process team, licensed the EV6 bus protocol and let these guys design a CPU. That CPU was termed "Athlon" when it was released and we know the rest of the story. For a long time AMD hasn't been allowed to make Intel clones, so what they do instead is implement the x86 ISA on the front end of their CPU's while the inside is a RISC processor. This HW abstraction layer lets them capitalize on the benefits of RISC (register renaming, predictable execution times) while maintaining compatibility with x86 software and compilers.

This is vs something like SPARC which is a pure RISC standard, no front end instruction decoder required.
 
Status
Not open for further replies.