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).

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

[mwvdlee]

hint: it's not going to be called windows 8.

Yes, it would be uncharacteristic for MS to settle on a versioning scheme.
We've already had version numbers, two-digit years, four-digit years, single-digit numbers, acronyms and names.
The only thing left is using nonsensical symbols like Prince did; TOSFKAW.

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

[spiffmastercow]

We moved away from x86 over a decade ago.. The instruction set for x86 is emulated in hardware. But yeah, hopefully this will mean at least a move to a sane assembly language. Not that anyone even uses assembly anymore...

Re:Good

[betterunixthanunix]

The microarchitecture argument is not very convincing -- yes, the instruction set is translated, but in the end, you still expose the x86 instruction set. As an example, we still have to deal with floating point registers that are arranged as a stack, although some compilers (GCC for example) have a option to use SSE registers and instructions as an alternative. In general, x86 inherits a lot of very outdated designs, which can be very annoying when you are forced to deal with them (or which just waste space on the die if nobody uses them anymore).

Re:Good

[partyguerrilla]

RISC architecture is going to change everything.

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

[Sponge Bath]

It's been a long, long time since I've used assembler for a driver in Windows (Win 3.1/95) era, and I've never needed it for Linux. Even for core kernel devs it is more the exception than the rule. These days, the ultimate language of all time, C, rightfully rules for these tasks.

Re:Good

[Sponge Bath]

"VLIW, like in high-performance DSP's and certain niche processors, is the future."

I want an Itanium in my iPhone!

Re:Good

[RobertM1968]

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...

Ummm... yeah, kinda... other than the massive portions that are monolithic and definitely tied to the hardware in NT 4. XP has a HAL as well... guess which other versions do also? As a matter of fact, most OS's have a device abstraction layer. Such does not make a multi-platform OS, as both IBM (OS/2 PPC) and MS (Windows NT for certain RISC schemes) can tell you via the problems they had getting their operating systems to run on non Intel compatible hardware. Even with how modular OS/2 was (in comparison to Windows), there were still various problems due to... rewriting and/or recompiling the rest of the OS.

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.

Re:Good

[turgid]

Not that it matters at this point. VLIW, like in high-performance DSP's and certain niche processors, is the future.

Yes, VLIW has been the future since the 1970s.

Re:Good

[RzUpAnmsCwrds]

No it isn't. Way to lose the whole point, which is predictability of how many cycles an instruction takes.

Predictability does not exist on any modern CPU because of a variety of factors, including caches, super-scalar execution, out of order execution, and branch prediction.

On a load-store (which is the precise term for what most people call "RISC") architecture, roughly 1 in every 3 instructions is either a branch or a memory instruction. On a CPU with caches and branch prediction you cannot have predictable instruction latencies with memory instructions or branches because by definition caches and branch prediction are probabilistic techniques. If you miss the cache, there is a penalty depending on exactly which caches you miss. Then there's the fact that you throw in cache coherency on shared memory multiprocessor systems and the memory access times can now depend on what *other* cores are doing.

Most people don't understand this because their idea of what a CPU is stops at something like the classic 5-stage RISC pipeline. But the reality is that we need caches, branch prediction, multi-issue, and (in most cases) out-of-order execution to have high-performance. Modern ARM processors (Cortex A9) have all of these features, and even older designs (Cortex A8) have at least multi-issue, branch prediction, and caches.

The problem with VLIW is that it is based on outdated ideas on where the performance problem is. VLIW works great when you have super-intelligent compilers, minimal branching, and never wait for memory. In reality, with few exceptions (like loopy scientific code) you branch a lot and spend a significant fraction of your time waiting for memory (either further caches or main memory). The primary benefit of out-of-order execution is that it hides memory latency, which is something that you can't get with VLIW. It looks great from a throughput standpoint on paper (and, for certain code, it does very well) but in practice on general code it falls flat on its face because you simply cannot keep the pipeline full.

Opportunities

[Nerdfest]

I'd actually prefer they didn't. Joke as you will, it's an excellent opportunity for Linux to make inroads to the more casual user. The last one (netbooks) didn't get much time before Microsoft jumped in with XP netbooks.

Re:Opportunities

[Desler]

Yeah, I also prefer they don't cater to the wants of their customers rather than the wants of the minuscule minority that are fighting some petty OS war.

Re:Opportunities

[UnknowingFool]

If Microsoft's track record is a good indication, I would be happy if they DID go for it... can anyone count how many versions of Windows were targeted at tablets - and failed to get anywhere except niche markets like Home Depot's inventory carts? Heck, even skip the WinMo crap that was never suited for touchscreen.

Why MS failed at tablets was all they did was shove Windows into a different form factor. And then called it done. Now other than having a touchscreen and using a stylus instead of a mouse, Windows tablets were just very expensive laptops. In the many years MS pushed tablets, they only wrote one application that truly used touch. They however left the rest of the OS very keyboard/mouse centric. So for the average consumer, why would they buy an expensive touchscreen laptop that gave them no real advantage to buying a cheaper laptop?

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

[The O Rly Factor]

How are they going to explain to the million of Windows users that no application they know will work on ARM Windows?

Clever marketing that appeals to yuppies.

"Don't be left behind with slow stupid x86 Microsoft Office, upgrade to the new better more powerful Microsoft ARM Office today. It's newer so you know its better, and come on it has the word "Arm" in it, which means powerful, duh!"

Re:ARM Windows

[Bert64]

Windows 64bit is different, most 32bit applications run on it just fine and the 32bit consumer versions are crippled (ie wont support more than 4gb of address space, even tho the hardware is capable of it using PAE)...

Windows on ARM won't run x86 applications natively, and if they provide an emulation option it will be almost certainly be extremely slow.

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.

Re:ARM Windows

[UnknowingFool]

Read about LLP vs LP. MS choose LLP which introduced a new 64-bit data type: long long (that's not a typo) and kept a 32-bit type: long. In terms of backwards compatibility, LLP means you don't have to recompile or do anything to have your 32-bit program still work. However you cannot simply recompile a 32-bit program to take advantage 64-bit; you actually had to change source code and compile. In some cases, it was going to be a simple find and replace; in other cases, it wasn't that easy. This means that going forward, you would have to maintain two different source code trees thus two binary versions.

The LP model redefines "long" to be 64-bit. Unless there was some weird code that blew up if "long" went above 32-bit, all that would be required was a recompile. You would have to maintain two binary versions but you could maintain one version of source code.

Re:ARM Windows

[LO0G]

The switch from 32bits to 64bits *is* going to break some set of applications. There's simply no way to avoid it.

If you use the LP model, you're going to break every application that assumes that sizeof(int) == sizeof(long). Call this set IntEqualsLong.
If you use the LLP model, you're going to break every application that assumes that sizeof(int) == sizeof(void *). Call this set IntEqualsPointer.

The question is: Is the set of applications in IntEqualsLong greater than the set of applications in IntEqualsPointer?

If you believe that IntEqualsLong is larger than IntEqualsPointer, you want to chose LLP (because it breaks fewer applications). If you believe that IntEqualsPointer is greater than IntEqualsLong, you chose LP.

Apparently the Windows developers thought that IntEqualsLong was greater than IntEqualsPointer. The Linux developers chose differently.

Re:ARM Windows

[mbkennel]

The CIOs dealing with thousands of seats requiring little more than Microsoft's suite, few easily ported business applications and a browser will appreciate that no application that their Windows users want (except Office, and the small number of official applications) will work on ARM Windows.

Lack of compatibility is a feature, not a bug.

Now they don't have to justify "why don't you let me install my XYZ" any more.

They just say "OK go ahead and try it" to their lusers, knowing that it won't work.

Those people with "mission critical legacy apps", well, they don't get new computers. Ever.

MS Windows supported RISC 15 years ago ...

[perpenso]

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

MS Windows NT 4 supported RISC 15 years ago in 1996(*), Dec Alpha, IBM/Motorola PowerPC and MIPS. All on the standard Win NT 4 retail CD. Consumer oriented PowerPC machines were available. I recall Byte magazine comparing dual PowerPC and dual x86 systems. Alpha machines were available for the more serious users. Despite better computational performance on the RISC based machines x86 won due to price and software availability. ARM could fail as well. ARM may have better battery performance but is it so much better that it will outweigh the software availability issue?

Also as other have pointed out the x86 has a RISC core. x86 instructions are converted to RISC instruction on-the-fly, scheduled and executed. The "problem" is that we do not have direct access to this core and must go through the x86 facade.

(*) OK you can argue 1993, day 1 for Win NT, since MIPS was supported. However I don't think there was any real push towards a consumer MIPS machine. The motivation was more internal, making sure Win NT was portable to other architectures.

Re:MS Windows supported RISC 15 years ago ...

[the linux geek]

Actually, MIcrosoft pushed for a MIPS reference architecture (ARCS) to be the successor to the PC architecture. They had some substantial support onboard, but it ended up breaking up due to DEC and a couple of other manufacturers pushing for Alpha to be the processor to be used, and then Compaq leaving and returning support to PC-compatibles.

Re:MS Windows supported RISC 15 years ago ...

[DarkOx]

The software issue might not be as big this time a round. Netbooks aside, ARM is driving today's tablets, cellphones, and embedded devices. That seems to be where computing is going in general. It simply won't make sense to bring most of the existing PC software into that world. The software that does make sense to go there is cross platform already. Hell I am running ArmedSlack on my GuruPlug and its package for package almost exactly the same as the x86 Slackware versions.

So people are really not going to be looking to move as many legacy apps over in the first place, frew applications people are really using will prove to be prohibitively difficult to port. Its not 1985 any more and we are not worried about running our DOS apps much, few applications written in the past 10 to 15 years have blobs of assembly sprinkled in and probably fewer make assumptions about PC hardware.