Microsoft and Qualcomm Collaborate To Bring Windows 10, x86 Emulation To Snapdragon Processors (anandtech.com)

An anonymous reader quotes a report from AnandTech: Today at Microsoft's WinHEC event in Shenzhen, China, the company announced that it's working with Qualcomm to bring the full Windows 10 experience to future devices powered by Snapdragon processors. These new Snapdragon-powered devices should support all things Microsoft, including Microsoft Office, Windows Hello, Windows Pen, and the Edge browser, alongside third-party Universal Windows Platform (UWP) apps and, most interestingly, x86 (32-bit) Win32 apps. They should even be able to play Crysis 2. This announcement fits nicely with Microsoft's "Windows Everywhere" doctrine and should come as no surprise. It's not even the first time we've seen Windows running on ARM processors. Microsoft's failed Windows RT operating system was a modified version of Windows 8 that targeted the ARMv7-A 32-bit architecture. It grew from Microsoft's MinWin effort to make Windows more modular by reorganizing the operating system and cleaning up API dependencies. The major change with today's announcement over Windows RT and UWP is that x86 apps will be able to run on Qualcomm's ARM-based SoCs, along with support for all of the peripherals that are already supported with Windows 10. This alone is a huge change from Windows RT, which would only work with a small subset of peripherals. Microsoft is also focusing on having these devices always connected through cellular, which is something that is not available for many PCs at the moment. Support will be available for eSIM to avoid having to find room in a cramped design to accommodate a physical SIM, and Microsoft is going so far as to call these "cellular PCs" meaning they are expecting broad support for this class of computer, rather than the handful available now with cellular connectivity. The ability to run x86 Win32 apps on ARM will come through emulation, and to demonstrate the performance Microsoft has released a video of an ARM PC running Photoshop.

Comments

Will apples one be app store only or will they do

[Joe_Dragon]

Will apples one be app store only or will they do same and let it run any app?

ARM Server CPUs, x86 on ARM

[HalAtWork]

I feel a transition coming for the low end... Wonder how Intel feels?

Re:ARM Server CPUs, x86 on ARM

[ausekilis]

Intel has seen the writing on the wall for some time now, that's why they've been pushing the Atom and i3 chips to lower and lower power consumption. They need to get some level of parity with the ARM chips or those areas where ARM excels (low power, low heat) will be eating Intel's lunch.

The Intel powered phones weren't quite there in power consumption, but they certainly had processing power. With ARMs becoming more ubiquitous and general-purpose, you can bet your ass Intel is pushing to keep their hardware in use.

Re:ARM Server CPUs, x86 on ARM

[Anonymous Coward]

> A Qualcomm ARM CPU is never going to be ridiculously better than a Samsung ARM CPU because they are both ARM designs, same cores, same roots, same everything

Apple's A10 seems to blow away the other ARMs in single core performance, and is reasonably close to entire SoCs. Granted that is SoC not just CPU, and there's more underneath those benchmarks that might push it towards a tight integrator like Apple- but it really does feel like there are practical differences even amongst ARMs.

If you have more details than I on this, please share though.

Re:ARM Server CPUs, x86 on ARM

[unixisc]

When Intel had XScale, that was DEC's StrongARM, and DEC was noted for high performance, but never low power. The XScale was fine as an embedded CPU but not for low power applications, which is why it went nowhere.

Re:ARM Server CPUs, x86 on ARM

[caseih]

So far in the micro server and embedded space, ARM has been particularly disappointing to me. I have a drawer full of ARM devices I've accumulated over the years. SheevaPlugs, GuruPlugs, RouterStation, etc. All are potentially useful devices, but ARM is hobbled by proprietary boot systems and differing device trees and proprietary supporting hardware. These devices rely on customized linux distributions, and they are often fairly hard to update to new kernels and new flash file systems. Some of these devices have good CPU performance specs, but in practice I've never had them outperform an intel-based server, even a small low-powered one like the atom.

And now in embedded space we have a plethora of Arm-based devices based on lots of different SoCs from companies all over the world. All with their own forks of Linux. We've got Raspbery Pis, Orange PIs, Pine64s, etc. All very interesting and probably useful. But a nightmare to do anything with in a sustainable way.

The Pi (and some of these devices) at least is easy to update since everything comes off of the sd card, with no kernel flashing required. And some of them like the Pi have a fair amount of hacker inertia behind them, so they are capable of doing cool things (maybe not as server replacements though).

With x86-based embedded systems and small servers, at least I can run more standard, off-the-shelf distros on them. I'd far rather deal with a conventional linux server than a sheevaplug, even if the sheevaplug is a nice tiny thing with lots of potential.

In fact my current home office router is a small, low-power Intel-based computer running bog standard, minimal install of CentOS 7. Wifi is hung off of that using a consumer-grade access point running in bridge mode.

If arm devices had a standard boot process like ufi or even the bios, and could boot off of a variety of devices in a standardized way, including ssds, hard drives, usb sticks, and internal flash storage, and could run stock distributions downloaded from distribution web sites, without custom kernels, then I'd say for sure x86's days are numbered. Arm is good at remaining fragmented though.

Re:ARM Server CPUs, x86 on ARM

[PCM2]

When I've heard people talk about "ARM servers," the fine print tends to be that they're not really talking about ARM CPUs, they're talking about ARM SoCs ... so however many ARM CPU cores paired with other components that tailor the SoC for specific workloads. The resulting ARM servers probably won't be general-purpose hardware for everybody to use, they will be marketed to people who know the specific thing they want to do and now they just want to hit the sweet spot on power consumption/cost/whatever.

Re:ARM Server CPUs, x86 on ARM

[Anonymous Coward]

The ARM platform mess is likely one of the reasons behind the rapidly growing support for the RISC-V architecture. The more obvious one being that no one wants to pay rent in perpetuity. ARM may not be as bad as intel, but they are definitely still a substantial burden on hardware developers, and a good open architecture and platform is what just about everyone wants. With Android being mostly platform neutral, I think ARM will also be in for a rude surprise, and turn out to have been a foolish investment for Softbank.

Re:ARM Server CPUs, x86 on ARM

[Big Hairy Ian]

I wonder if they'll transition Windows Server as well https://hardware.slashdot.org/...

Re:ARM Server CPUs, x86 on ARM

[Anonymous Coward]

Why does Apple's ARM CPU win only in single core performance but not multi core? There has to be a catch somewhere.

I wonder if it can run Virtualbox?

[Anonymous Coward]

I could run a VM that run Linux using this.

Re: I wonder if it can run Virtualbox?

[Anonymous Coward]

Nope. Virtualization is not really an ARM thing. Intel jumped through huge hoops to provide virtualziation extensions, and all the software is written for x86- and not in the "change a constant" sorta way.

I wiggle my piggy buttocks with joy

[Anonymous Coward]

cuz linux r00lz!

And in war we all know...

[Anonymous Coward]

what happens to collaborators.

Code re-writing?

[Anonymous Coward]

Presumably code re-writing? But if the program was worth selling for an ARM v8 platform, then it would be worth re-compiling and optimizing for an ARM v8 platform!

I think this is for legacy apps only.

Re:Code re-writing?

[tepples]

Developers wanted to recompile their x86 Windows desktop applications for the desktop on Windows RT. Microsoft refused, instead decreeing that the only desktop applications on Windows RT shall be File Explorer, IE, and Office.

Re:Code re-writing?

[Alain Williams]

Or maybe this is an admission by MS that it cannot easily port its stuff to non Intel or perhaps not manage a mixed processor infrastructure (s/ware downloads, updates, ...)

Emulation has got to be slower or use more power (== electricity) to achieve parity.

Performance?

[crunchy_one]

According to TLA, x86 compatibility is achieved through emulation. Emulating the x86 instruction set is a non-trivial exercise that almost invariably results in extremely disappointing performance. Why? The x86 instruction set is an accretion of the instruction sets of older Intel processors, beginning with the 8008. This yields a difficult (i.e., computationally expensive) instruction set to decode and execute. Over the years, Intel has implemented micro-architectures that address this problem through special purpose hardware. If you're so inclined, have a read here http://www.intel.com/content/w... for details. The takeaway is that simply emulating the x86 instruction set results in about a 100x slowdown for an equivalent clock rate. So, although this is an interesting technology demonstration, I seriously doubt it will prove useful outside of a small set of applications. It will certainly not be a satisfactory gaming platform.

Re:Performance?

[mlw4428]

So you're saying it'll run Crysis?

Re:Performance?

[kronix1986]

"The takeaway is that simply emulating the x86 instruction set results in about a 100x slowdown for an equivalent clock rate. So, although this is an interesting technology demonstration, I seriously doubt it will prove useful outside of a small set of applications. It will certainly not be a satisfactory gaming platform."

Sounds like you didn't read the article or watch the embedded video, where MS show x86 Photoshop and x86 World of Tanks being emulated on Windows 10 ARM and a Snapdragon (835?) SoC - and running fine.

Re:Performance?

[crunchy_one]

Don't believe everything you read/see in a press release. Apply some critical thinking.

Re:Performance?

[Halo1]

The takeaway is that simply emulating the x86 instruction set results in about a 100x slowdown for an equivalent clock rate.

Emulation definitely results in slowdowns, but it's generally much less than 100x. In particular since any emulator that focuses even slightly on performance uses dynamic compilation: it translates the code once from x86 to the host architecture and from then on runs this translation. The translated version will probably be less efficient than the original code, but by no means 100x slower. 2x to 5x seems more realistic on average, although there are certainly outliers (e.g. code that intensively mucks with system registers or that triggers context switches will be slower, while some straightforward calculation loops may actually become just as fast as or even faster than the original code depending on the target architecture's nature).

Re:Performance?

[Anonymous Coward]

As an AMD engineer put it, x86 is not difficult, just strange.

Re:Performance?

[ET3D]

I believe press releases (particularly when coupled with demos) a lot more than I believe random people on the internet. That's applying critical thinking.

Re:Performance?

[__aaclcg7560]

So you're saying it'll run Crysis?

The Cyrix processor was a nice low-end processor with great Linux support back in the Socket 7 days. But no one wants to emulate that processor today.

https://en.wikipedia.org/wiki/Cyrix_6x86

Re:Performance?

[GoRK]

Your information is highly dated and perhaps your sources are also a bit biased. At any rate, 100x performance hit is stupid wrong.

Static translation was achieving 50-70% native performance rates (measured against clock cycles) with FX!32 on Windows NT for Alpha in the mid 90's. The problem of course has been very well studied since then particularly with the advent of virtualization and the x64 instruction set and the need to enhance the performance of x86 code running on even Intel's own platforms. Furthermore for any particularly glaring issues that are the fault of the hardware -- well it is much more easily tuned today than it once was. A bespoke opcode or extra register to assist in a specific task is no longer a monumental engineering undertaking today -- it is a matter mostly of dev/test/validate.

The approach taken with x64 to support x86 native execution is quite different than attacking the problem with emulation. Is there a performance hit? Certainly, but a hit of 10-20% simply doesnt make up for the fact that you might be able to have an 8 core ARM for the same price and power budget as a 2 core x86 mobile cpu. The applications that lose in this scenario are the ones the rely on raw single thread performance. Certainly some games are in this camp, but many games which make efficient use of threads are not.

Re:Performance?

[bluefoxlucid]

It depends on if they emulate it by translation and shadowing, or by interpretation. Software translation is rather fast, but not native-fast. To get native-fast, you have to go native.

I've been suggesting an accelerator chip (maybe even off-die) that decodes x86 instructions into the internal RISC instructions stored in the ICache, but people keep telling me it's impossible because... they're stupid. Modern x86, x86-64, and ARM chips all read instructions in their ISA and translate to an internal CPU RISC ISA, to the point that x86-64 chips actually translate x86 instructions to take advantage of around 60 hardware registers thanks to having not just twice as many GPRs (16!), but those GPRs being 64-bits wide (32 GPRs), plus the EBP, ESP, and EIC registers being 64 bits wide and only validly addressing a 32-bit address space (3 more registers). Multiple instructions hitting the same memory won't just work on cache (fast), but will actually load that cache line to register (extremely fast) and operate a series of instructions there--even out-of-order instructions.

No doubt the instruction decoder would be large-ish, and access to its own (I4) cache would prove a performance boon if that cache is kept consistent with actual RAM. Nevertheless, it should be roughly-trivial to produce a CPU chipset that can execute both x86-64 and ARM64 code, in the same way it's roughly-trivial to produce a CPU chipset that executes both x86 and x86-64 or ARM and THUMB. These aren't simple tasks by any means; but the fact is we routinely create chipsets which execute an ISA, and chipsets which execute multiple ISAs, and even chipsets which execute old ISAs while automatically leveraging internal facilities such as registers available to new ISAs (which isn't impressive when you think about OOE, parallel execution, and branch prediction). x86-64 is related to x86, but only at face value; they're different instruction sets, just like ARM and MIPS are different, and it should be fairly easy--not cheap, mind you--to wedge x86-64 in with ARM.

Re:Performance?

[Anonymous Coward]

what if you only emulate a subset of the x86?

If you want application compatibility, not full system compatibility. Emulate 32 and 64 bit user mode instructions only. (I say this with the assuming the goal is not to run 8086 DOS apps from the 1980s directly on the hardware.*)

That is, if this emulation is for a phone/tablet/pda, the real OS will be written in ARM's ISA, so worrying about HLT, CLI, IOB, etc won't be an issue. Throw a general protection fault: invalid instruction, and move on.

*And if you are the type of person who genuinely wants to run 1980's DOS apps on this snap dragon processor, you're not the market worth catering to.

Re: Performance?

[K. S. Kyosuke]

I believe that Dynamo/RIO or how that thing was called actually managed to occasionally produce code *faster* that the original, if said code was generated with an inferior compiler.

Re:Performance?

[drinkypoo]

The applications that lose in this scenario are the ones the rely on raw single thread performance. Certainly some games are in this camp, but many games which make efficient use of threads are not.

It's not that simple. Games are multithreaded now, yes, but they do not have a crapload of threads which can make use of a crapload of cores. If you're taking a substantial clock rate hit and another substantial hit from translation overhead, the truth is that it's not just the high-end games which are going to suffer, nor the low-end ones, but any of them which are not very old — as defined by coming from the era when PCs had even lower clock rates. It's already true that Intel processors with less cores still beat AMD processors in gaming benchmarks, notably in the area of minimum frame rate — the torque of graphics performance, where the max frame rate is horsepower. We all like high max frame rates, but high minimum frame rates are what really matter. (price:performance is also relevant, which is why I went AMD anyway; both CPU and motherboard are cheaper, which translates into a big savings at the system price level. I am not in competition, and I can live with slightly degraded graphics.)

Re: Performance?

[Halo1]

Back then it was still Dynamo. And they only managed to do that on a particular HP PA-RISC architecture, because it was very sensitive to instruction cache missers (or had a bad branch predictor?) so that creating linear traces of code was very performant. They later tried to reproduce it on x86 and failed horribly (just like I did during my master's thesis; the best I got was a 20% slowdown for gzip, I think the best they got was no performance loss with some benchmarks).

Re:Performance?

[chispito]

Don't believe everything you read/see in a press release. Apply some critical thinking.

A reasonable person that both watches the video and reads your comment would conclude that either you are mistaken, or Microsoft and Qualcomm have somewhat overcome or mitigated the issues you point out.

Re:Performance?

[maestroX]

Much less than 100 times alright, but somehow most JITs/emulators (hello Transmeta) manage to incur a ridiculously high load on the system so running multiple large emulated apps simultaneously is troublesome. Why not distribute in CIL or llvm IR format?

Re:Performance?

[Halo1]

Having an intermediate format that you statically translate into the target architecture is definitely useful (like Android is now doing with ART), but keep in mind that LLVM IR is not architecture-independent most of the time. E.g., when LLVM IR is generated from C, then this C code will at least have been compiled based on a certain pointer size, size of long, size of long long, alignments for struct fields, etc. CIL is better in this regard.

However, you should see this as a solution that will be used in an addition to running native apps, not as something you promote to do instead. It probably mainly because it seems unlikely that all, or even many, developers will start shipping tons of Windows 10 AArch64 applications right away. It's a bit like how Apple shipped Rosetta with the first Mac OS X versions for Intel Macs so they could emulate PowerPC apps (and an m68k emulator with the PowerPC versions of classic MacOS), while at the same time encouraging developers to start creating native Intel apps.

Re:Performance?

[Anonymous Coward]

The translated version will probably be less efficient than the original code, but by no means 100x slower. 2x to 5x seems more realistic on average, although there are certainly outliers (e.g. code that intensively mucks with system registers or that triggers context switches will be slower,...

In my experience the biggest outliers are invariably graphics. The best hope is some sort of high-level DX -> OpenGL ES translation library (or at least a thunk of of some sort if the graphics chip supports DX), but I honestly don't see that working out very well. It's not that it can't be done, of course. It's that even hardware-based virtual machines are horrible with any/all 3D graphics even though fundamentally they're in the best position to provide that sort of support. Even doing graphics card pass-through is a pretty horrible mess.

If MS actually wanted to do what they say they wanted to do with the least amount of effort? Invest energy into developing WINE on ARM. Of course that'd have the unintended side effect of vastly improving WINE compatibility on x86/amd64, so fat chance of them doing that. Other than that, I just don't see this as yet more marketing BS. Perhaps I'm just jaded because of how much emulation has turned out to be such a disappointment. Sure, you can play your games or run your programs on another system. In the end, though, are the countless graphic and auditory inaccuracies, the need for frame skipping, and the general inconsistency that comes from the mindset that good enough is good enough*. Microsoft is the "good enough" company.

* You could claim BSNES/Higan as breaking from this and certainly byuu has at least tried at some level to be more compatible, but Star Fox desyncs compared to the real hardware. Honestly, until I see an SNES emulator managing Star Fox properly, I don't think I'll be content on the issue. Same with most PSX games that have stutter problems at some point in game play.

Re:Performance?

[im_thatoneguy]

I think it's safe to say it's slower, but as I used to remind the engineers when they pushed back against releasing slow solutions when I was working as a liason between customers and engineering: "not working is infinitely slow".

It's easy to see how Microsoft wants this for the Surface Phone since it will allow customers to run x86 applications on their phone. If your choice is between not running an application and running it slowly, most people will always choose "slowly". Most Win32 software isn't high performance software. And a lot of the really computationally hard stuff is getting moved to GPU anyway. So for instance photoshop has shifted much of its filtering and canvas rendering to OpenCL/CUDA. The Snapdragon should have a perfectly adequate if not superior OpenCL benchmark compared to a low-end intel built in GPU. Same with games. Even if you take a pretty large performance hit on CPU cycles, usually it's the GPU bottlenecking not the CPU. So their magic emulator should natively execute all DirectX/OpenGL calls on the GPU anyway.

The Xbox team has done a great job of this on the Xbox One backwards compatibility for PowerPC RISC support on the Xbox One.

Re:Performance?

[Anonymous Coward]

I love how know-it-alls pop up brightly and spout off nonsense that doesn't apply in the real world. In the real world, where I live, emulation has never been a viable general-purpose solution. It sucks, the performance sucks, and often there are functions that cannot be emulated at all.

It's not "probably less efficient", it's less efficient. I challenge your estimate of only 2X - 5X slower, but lets just use your numbers for a second. For the sake of argument you understand.

I have 3 computers in my life. One bitchin' fast, the other two are dog slow. I can't fix the performance of the dog slow systems because the things that make them slow are outside of my control. Now make those computers 2X - 5X slower. Can you see how I might not be enthusiastic about your supposedly low overhead emulation system?

But you say, then you have bigger problems! Yeah, and that's exactly my point. I have bigger problems, and I have no interest in running a slow-ass emulation system on ARM processors, just to prove that I'm hard-core or something. Who the hell wants or needs x86 emulation on ARM? We have perfectly good real x86 chips to do this job. So use them!

Re:Performance?

[Anonymous Coward]

Besides performance, one big problem with games may be their copy protection systems, which are designed to detect if they are ran under emulation or virtualization. Copy protection systems have been biggest reason why many games required administration priviledges and/or refused to run on newer windows versions.

Re: Performance?

[K. S. Kyosuke]

If you could get (say, on ARM) that 20% slowdown for code transpiled from x86 binaries (with a native build being the baseline), I guess you'd be very happy? And so would we. This *could* be useful.

So lame

[Anonymous Coward]

Why an emulator? Is Microsoft, one of the biggest software makers in the world, not capable of porting their operating system to other architectures?

Re: So lame

[Anonymous Coward]

...The OS is native. If you want to run an x86 app, the OS automatically launches it under emulation.

Re:So lame

[DarkOx]

They are prefectly capable, and have done so. Actually windows is pretty (NT train on which everything current is based) is pretty cross platform.

What Microsoft can't do is get every other vendor in the world to port all their x86 code, and rebuild all their x86 binaries, where the source is otherwise free of x86 assumptions about pointer size, etc.

Re:So lame

[Anonymous Coward]

Microsoft knows a great deal about cross-platform development.

Microsoft Office was originally written on 68k Macs then ported to x86 and Windows.

Windows NT (everything post Win 95/ME) was written for the MIPS R1000 and then ported to the x86. Windows NT has always been officially supported on at least one other architecture besides x86 (over the years this has included MIPS, Alpha, Itanium, ARM). The much-maligned Surface RT actually ran a full version of Windows NT Home Edition; Microsoft however made the retarded decision to lock down that version of windows to only allow applications that had been signed by Microsoft themselves, in order to ensure a monopoly position for their app store as the sole source for applications, and then further restricted it to their gimped justly-maligned Metro API. Except for their own Office apps, which were full-blown desktop apps with an early version of their current metro-ish look and feel. Because they're special, and they hate you.

The problem is the ISVs who are less interested in porting their software to a marginal platform and supporting it there. And they're still pissed at Microsoft for the WinRT debacle.

Re:So lame

[jabuzz]

You need to add in the ridiculous licensing on the version of Office shipped with the SurfaceRT (it was Home and Student version so unusable for business) and complete lack of Outlook at launch that basically killed the product.

Re:So lame

[unixisc]

Not all the apps are written by Microsoft, so they have no control over what gets ported. While they have written Office natively to the ARM viz Office for WIndows 10 Mobile, other apps that the phone may need may not be there.

But I still am not getting the point. The applications that one runs on desktops - not talking about email here - are different from the ones one runs on phones. For instance, things like WhatsApp, Yelp, Fandango, et al are there on Windows Phone, but not on x86: for the latter, one has to open a browser and run from there, or in case of WhatsApp, download the client and make sure the phone version is running. There are a lot of apps missing on the Windows Mobile platform, such as Lyft, Vonage, RetailMeNot, which don't exist on x86 Windows either, so making a phone that runs desktop apps - be it native or via emulation - ain't gonna do a thing for the platform. If anything, the Lumia, whatever its current shortcomings, is certainly more capable than what a Surface phone w/ a similar processor but emulating desktop code is likely to be.

Another point - most of the x86 apps out there are ones written w/ Windows 7 in mind, not Windows 8 or 10, and in that department, they won't do a proper job projecting themselves on a Surface phone

Not all emulation

[Anonymous Coward]

Only the Win32 x86 apps are emulated. The Win64 bit ones are not, and neither is the OS. That is why the performance is good (check the video). Hope that helps.

Re:Not all emulation

[Guspaz]

The Win64 ones aren't emulated because they simply aren't supported.

Re:Not all emulation

[PCM2]

That's not actually that big of a downside. With Microsoft Office, for example, Microsoft still recommends most users install the 32-bit version, even though almost everybody is running a 64-bit OS these days. The exception is people who need to run crazy big Access databases (or ... shudder ... Excel spreadsheets).

Re:Dear Microsoft, please don't

[Anonymous Coward]

I for one welcome real Windows running on more processors. Microsoft is the only one who understood the importance of developers and, and this is real important so listen up Google, provided functional developer tools. Android is a fucking joke; 7 versions and still missing basic functionality like ODBC support. No, I don't want to write 90% of a web application and then fight your dumb terminal to display it. I want a real native app with real native features.

FX!32

[DrXym]

Microsoft produced a version of Windows NT for DEC Alpha and threw in x86 emulation layer called FX!32 so it could run existing software. It worked but it ran like a dog, far slower than native x86 instructions. And not for want of trying because it did machine translate instructions to try and execute code natively.

I really don't expect the picture to be any different with x86 over ARM. I expect they'll machine translate x86 instructions into native ARM instructions in some way and cache them somewhere, but the results won't get anywhere close to x86 performance and there'll be a whole bunch of caveats about software it will or won't run. It'll probably be fine for running more sedentary apps.

I very much doubt anybody will be playing Crysis 2 on it. In fact I'd be surprised if any remotely demanding game played on it. Not just just because of the emulation but because no game would be tested with the GPU so they are liable to break hard for one reason or another.

Re:FX!32

[Anonymous Coward]

FX!32 was a DEC thing, not a Microsoft thing.

Re:FX!32

[Anonymous Coward]

John Burdette Gage w/ Sun Microsystems said: "The network is the computer."

Now, some dumbass with Microsoft is saying: "The cellular network is the computer."

Re:FX!32

[__aaclcg7560]

Now, some dumbass with Microsoft is saying: "The cellular network is the computer."

It is when you consider that the most commonly owned computers are smart phones.

Re:FX!32

[Anonymous Coward]

Impossible! They don't run Windows and people are used to Windows so retraining to use something other than Windows is too expensive. Come on, Get The Facts will ya.

Do people still think what comes out of Microsoft's PR department is bound to reality? Oh wait, there were millions of American's who voted for a guy name Donald Trump so I guess that might answer the question. Fool me once shame on you, fool me twice shame on me. Fool me over and over it's Obama's fault or Clinton's fault, or someone else's fault.

x86 on ARM is a dumb idea and that's been proven over and over again. It'll waste time and the only benefit for Microsoft is it'll allow them to spend their money to get fingers deep into certain companies and screw them over. Thinking Nokia for a recent example. Watch the companies Microsoft pays to do these things and look to see what technology they have or market share they have and how it would benefit Microsoft to own it.

Re:FX!32

[MightyMartian]

If there were lots of ARM desktop systems out there I could understand it, but as it is, ARM is almost solely still an embedded, tablet and smartphone ecosystem. Having used classic Windows apps on an 8" tablet, I can't imagine any sane person wanting to run them on a phone, or even an 8" tablet.

Re:FX!32

[unixisc]

Also, FX!32 was meant to be a stopgap solution until users of major NT titles that were run under the Alpha would prove to the ISVs that it's worth recompiling their titles for the Alpha. Which never happened, due largely to Microsoft's lack of support. It won't happen here either. For some reason, Android succeeded where OS/2 failed - being first to market helped, and the fact that there was another illustrious alternative in iOS ensured that the market had what it needed

Re:Will apples one be app store only or will they

[ET3D]

It was already rumoured in the past that Apple was planning to switch to ARM for Macs. That would imply similar emulation. That said, it likely won't mean opening iOS.

smoking crack for breakfast

[Anonymous Coward]

2x to 5x seems more realistic on average

your "feelings" are bizarre to say the least

while some straightforward calculation loops may actually become just as fast as or even faster than the original code

yeah now you've graduated to the hard stuff

Re:smoking crack for breakfast

[Anonymous Coward]

It's actually not as crazy as it sounds.
It's entirely possible that a dynamic compiler has better optimization than the static compiler that compiled the original code, especially with all of the "different" x86 architectures around. Code optimized for the original 80386 would not run as well on i7 as code optimized for i7.

A dynamic compiler also has run-time information, and could know, for example, that a certain branch was taken 99 times out of the last 100. Great if the static compiler guessed right at compile time, but nearly the worst case if it guessed wrong. Or, going even further, a dynamic compiler would know that it's not taken at all if jumped to from function A, but almost always taken from function B, and optimize accordingly.

And, after running for a while, this is all native code in the native instruction set.

There was a paper I read decades ago about this, but I don't remember enough to look it up again.

Re:Will apples one be app store only or will they

[__aaclcg7560]

Supposedly Apple has Mac OS (or OS X) running natively on ARM processors. The only emulation needed will be for legacy programs, which is what they did for PowerPC programs after switching to Intel processors.

dont count AMD out ZEN intel loses and ARM loses

[Joe_Dragon]

dont count AMD out ZEN intel loses and ARM loses

Re:Dear Microsoft, please don't

[__aaclcg7560]

No, I don't want to write 90% of a web application and then fight your dumb terminal to display it.

You don't support Lynx text browsers? Bastard.

how loud will the cooling fans need to be

[Anonymous Coward]

Bolting things onto the ARM to run x86 Windows will require more processing power, more RAM, more cache, more power and more heat. Blow me.

Re:dont count AMD out ZEN intel loses and ARM lose

[Guspaz]

That's the same thing that AMD has been saying for every new chip for the past decade. They haven't had a hit since the Althon 64, and that was 13 years ago. I'll believe it when I see it, until then, I'll expect Zen to be a repeat of the Bulldozer disaster. I'd like for it to turn out to be another Athlon 64, though: it's been a very long time since there has been any competition in the x86 market.

Data execution prevention

[tepples]

In particular since any emulator that focuses even slightly on performance uses dynamic compilation

Except a lot of mass-market ARM platforms nowadays have W^X security policies that ban dynamic compilation.

Re:Data execution prevention

[Halo1]

That only means you have to mark the pages containing the code you just generated read-only once you're done.

Middle ground between user and ring 0: drivers

[tepples]

If you want application compatibility, not full system compatibility. Emulate 32 and 64 bit user mode instructions only.

Do you foresee ability to plug a peripheral into one of these Snapdragon devices through a USB OTG or USB C adapter and run its device driver correctly?

General purpose?

[tepples]

There is a computer in your microwave oven.

Do these "most commonly owned computers" that you mention offer general-purpose functionality when connected to an external monitor and paired to a Bluetooth keyboard, including the ability to take one tool's output and use it as another tool's input without needing each tool to be specifically aware of the other tools?

Re:General purpose?

[__aaclcg7560]

There is a computer in your microwave oven.

There are computers everywhere. But the smart phone is similar to a PC than microwave oven.

Do these "most commonly owned computers" that you mention offer general-purpose functionality when connected to an external monitor and paired to a Bluetooth keyboard, including the ability to take one tool's output and use it as another tool's input without needing each tool to be specifically aware of the other tools?

GE has a line of Bluetooth-enabled appliances. Not sure about external keyboard and monitor support.

URL:https://www.cnet.com/products/ge-profile-pgb940/preview/?

Re:General purpose?

[Anne Thwacks]

I for one, can't wait to have a keyboard and 27" monitor on my microwave. I just don't want SystemD.

Try a docking station

[tepples]

Having used classic Windows apps on an 8" tablet, I can't imagine any sane person wanting to run them on a phone

Not even on a phone paired to a keyboard and connected to a 24" external monitor?

Re:Try a docking station

[MightyMartian]

I've done it with a tablet and it works, but I own a notebook and have a desktop PC at work so I see little enough reason to do it. In theory I suppose the idea of using a mobile device as your primary computing device has its attractions, but this would also mean for me having a Windows device or a device capable of running the Windows software I do use, and the cost of Windows smart devices is fairly hefty.

Re:Will apples one be app store only or will they

[unixisc]

That would be a good idea. It would enable them to run iOS apps natively under OS X, and leverage the installed base of iOS apps in the Mac space.

Re:Dear Microsoft, please don't

[unixisc]

But Microsoft has a horrible record on that - remember NT on RISC? Given that record, I don't trust them on this one. For the Surface Phone, I believe it only makes sense to do if the phone is x64 based, otherwise there is no reason to slay the Lumia. In fact, the Lumia would be a better phone than a phone that still has a Snapdragon but is now emulating x86, as opposed to one running native ARM apps, which is the case w/ Lumia

Re:Intel

[unixisc]

No, even if (take the worst case) x86 dies, Intel can still be a TSMC for the most advanced of semi companies. Don't forget - they also have Altera's FPGAs, and that market won't be going away anytime

3rd party apps lack privilege to re-mark pages

[tepples]

That only means you have to mark the pages containing the code you just generated read-only once you're done.

Several operating systems in wide use, such as Apple iOS and the operating systems of modern video game consoles, offer no way for third-party applications to switch a page from read-write to read-execute. When a page is allocated for data, the OS clears it first, and it stays non-executable until deallocated. Only the OS's executable loader* has the privilege to allocate pages for code, and once the loader loads a module, verifies its digital signature, and flips its pages from read-write to read-execute, the pages stay non-writable until deallocated.

* Or, in the case of Apple iOS, the WebKit JavaScript virtual machine.

Re:3rd party apps lack privilege to re-mark pages

[Halo1]

Given that this is a Microsoft-sanctioned emulator that they will include with their own OS, I think you can be pretty confident it will have similar permissions.

It's bitztream

[Anonymous Coward]

the autism-hating, custom EpiPen-hating, Musk-hating Slashdot troll!

They're trying TCG *again*?

[sethstorm]

Apparently Microsoft hasn't gotten the memo about restrictions not being wanted, so they keep on trying to do it?

Plus AMD sold us all up a creek:

[Anonymous Coward]

They could have provided user settable keys to boot up the trustzone engine, so that the end user had full control of their own hardware. But instead they decided to follow suit with Intel and the ARM ecosystem and made the Trustzone cpu (and other ME related microcontrollers) vendor signed, without provisions for end-user control of the accepted firmware key, and with userspace interaction with said core that is given 'superuser' level access to the entire system memoryspace.

While I know we are the minority, I am with the group of people abandoning all three cpu vending groups (Intel, AMD, and most of ARM) for not respecting my rights and control of my own hardware. >LGA775, >FM2(no +!), >AM3+, or ARM+TrustZone are all no go.