Taiwanese OEMs Consider ARM Products For Windows 8

siliconbits writes "At CeBIT 2011, we went around the stands from some of the biggest component manufacturers in the world and asked them a simple question, would you consider bringing out ARM products (barebones, laptops, tablets, motherboards) for Windows 8? The answer was a unanimous yes; like Microsoft, the same firms that have been faithful Intel and AMD partners for years are prepared to explore other territories as soon as Windows 8 will go live."

Comments

Dumb question - of course they'll say yes.

[tomhudson]

What did you expect them to say - "No, we won't - we'll cede that market to our competitors, because our customers prefer products with crappy battery life"?

Re:Dumb question - of course they'll say yes.

[RobertM1968]

What did you expect them to say - "No, we won't - we'll cede that market to our competitors, because our customers prefer products with crappy battery life"?

Parent is correct... and for even more reasons than indicated. (no, this next section is not a slam against MS... read through the whole thing) Sure, Win8 may bomb on such things (pick a reason: no interest, Microsoft yet again not fulfilling their promise to have something actually suitable for such devices, Win8's requirements being too absurd for such "minimalist" hardware, whatever)... but the simple fact is, it may gain traction and take off. On that possibility, there isn't one OEM with half a brain that would say "no, we aren't doing this" at this point in time. When the correct time comes to make a decision, they'll choose to (a) release some test bed units, (b) dive full in or (c) look away from Win8 and concentrate on other things - but now is definitely not them time for them to say no, especially under the possibility that they will need Microsoft's good will in the future (assuming Win8 proves suitable and desired on such devices).

Good

[betterunixthanunix]

OK, finally we are moving away from x86 and toward RISC. We are only 20 years behind schedule, but hey, better late than never.

Re:Good

[hittman007]

As I recall Windows NT 4.0 was independent of hardware. They had this concept they called HAL, which did all of the communication when it came to hardware. You had an alpha chip, no problem, just get a alpha HAL. I have in person seen Windows NT 4.0 running on other architectures, including alphas and apples of the day (long before they switched to intel equipment).

I'm guessing they dropped this capability with one of the newer incarnations...

Re:Good

[Kjella]

RISC won 20 years ago, all x86 processors decode to some internal instruction set. I am certain the engineers at Intel and AMD have tested exposing the native instructions and if it could perform much faster than x86 I'm sure they'd enable applications to bypass the hardware decoder and send micro-ops directly. While they still process the instructions the really obscure ones live in microcode instead of hardware, x86_64 adjusted the number of registers etc. so most things have been tweaked. I don't need to remind you that the last attempt to do better was the Itanic...

Re:Good

[Rockoon]

Most (all?) 64-bit compilers produce SSE single precision and double precision code by default. It is the x87 stack that is the odd-man out, contrary to what you are making it sound like.

All x64 CPU's support both single and double precision SSE, which is why its the default for 64-bit targets. If you are targeting a 32-bit OS, then a 32-bit binary cannot simply assume that single precision SSE is available, let alone the later double-precision support of SSE2.

Also, the x87 FPU performs calculations in 80-bit precision, so is not directly comparable to SSE's single and double precision features.

Finally, it is not "some compilers".. its ALL THE MAJOR ONES, both 32-bit and 64-bit.

ARM Windows

[devent]

How are they going to explain to the million of Windows users that no application they know will work on ARM Windows? It's the same as with Windows 64 bit and why we didn't saw much of it despite the prices for RAM are very low. I guess with Windows 7 the developers finally released some software for 64 bit. That's what, like 9 to 10 years since AMD came with the amd64 architecture?

Well, at least I can then finally buy some ARM notebooks and put a decent Linux distribution on it.

Re:ARM Windows

[UnknowingFool]

It's the same as with Windows 64 bit and why we didn't saw much of it despite the prices for RAM are very low. I guess with Windows 7 the developers finally released some software for 64 bit. That's what, like 9 to 10 years since AMD came with the amd64 architecture?

The reason 64-bit wasn't was adopted quickly was more about need vs features. The model MS choose for their 64-bit migration (LLP) meant that 32-bit programs were backwards compatible. So there was no need for a consumer to get 64-bit Office because 32-bit Office would work fine in 64-bit Windows. If all the 32-bit programs worked either way on 64-bit or 32-bit OS, there wasn't as much as a push to migrate. Unfortunately 64-bit Windows would often times require new drivers. So there were more negatives moving to 64-bit on Windows unless the consumer had a specific need like more memory addressing. For the most part, businesses were more open to using 64-bit Windows Server as there was a need in many cases to access more than 3GB of RAM.

Software companies that wanted to take advantage of 64-bit for Windows had to maintain separate 32-bit and 64-bit binary and source code versions during the migration. While the 32-bit version would work on either Windows flavor, the 64-bit would not work on a 32-bit OS. Many companies were reluctant to maintain two versions especially if moving to 64-bit provided no real advantage.

The Linux/Unix/OS X model (LP) took a different approach as that model focused more on forward compatibility. A 32-bit program could be made into a 64-bit program with a recompile and testing to ensure there were no special scenarios that required 32-bit addresses, etc. Software companies would have to maintain two binary versions but for the most part could maintain one version of source code. With Linux/Unix/OS X, a great deal of software was open source so that it was far easier to make this migration.