First I was amazed with them getting Xbox 360 (PPC) games running at full speed or better on the Xbox One (x86) and now we have x86 on ARM.
They have some wizards working on this stuff.
Edit: I wonder if Dave Cutler is involved in this x86 on ARM stuff? I think he was with the Xbox 360/Xbox One.
EDIT: https://en.wikipedia.org/wiki/List_of_Xbox_360_games_compati... "Unlike the emulation of original Xbox games on the Xbox 360, the Xbox One does not require game modification, since it emulates an exact replica of its predecessor's environment – both hardware and software operating systems."
I stand corrected.
> Xbox 360 games run within an emulator on Xbox One, which means you'll be able to use most features from both systems while playing games, such as screenshots, broadcasting, and Game DVR.
looks like api translation like wine does. ...which is rather easy if you wrote the original api.
I think they're kind of doing this already with Windows Defender App Guard [1] thing, which for one is a mouthful, second, it should have nothing to do with the exploitable Windows Defender code [2].
It should be part of Windows' lower-level systems, so that not much can interact with it, and it should be available for all apps, not just Microsoft's own apps. Windows on ARM, Project Centennial, App Guard, and more, prove that Microsoft has the ability to do that.
If they don't do it, it will only be for political reasons like not wanting Chrome users to benefit from the same technology, or wanting to sell it as "value-add" to enterprise customers, or whatever (basically the same BS they're pulling with Bitlocker).
[1] https://blogs.windows.com/msedgedev/2016/09/27/application-g...
[2] https://arstechnica.com/information-technology/2017/05/windo...
1. In the talk they claim that they get "near native" speed from the translation. Can we have some real number of what can be expected? What about warm up time?
2. Is the x86 translation layer only available in user space, or can x86 drivers be loaded for hardware that doesn't have arm drivers yet (or the manufacturer doesn't care about making them)
3. Are there any plans in the future for supporting x64 code as well in the translation layer?
Edit: One more:
4. Are there any plans on supporting Arm v7 in the future, e.g. with Surface/Surface 2 support?
I hope the answer is not "by restricting all emulated threads to one CPU core".
So, an emulator like this isn't going to be perfect, and applications which have been getting lucky due to x86's ordering model and avoiding proper sync primitives will likely break, and there really isn't much that can be done in those cases but fixing the application although it wouldn't surprise me if there is a compatibility flag which falls back to some slow path emulation mode which orders individual loads/stores and runs at 1/10 the normal speeds.
Although this is somewhat of the reverse in architectures, going from CISCy to RISCy.
The only thing that concerns em about recent Microsoft developments is that they seem very keen to move their OSes into more of a walled garden like iOS and the Mac App Store, and extract 30% from every third party application transaction. They could use one of these sorts of transitions as an opportunity to advance that business strategy further.
In the case of Windows in particular, it's a chance to leave the installation wizards, the registry and the DLL hell behind and use the packaged model that macOS adopted from the get go.
Apple did the same when they moved from 68K to PPC. The PPC would run the 68K code in emulation or, if it was a "fat binary" with both 68K and PPC code, it would just load the functionally equivalent PPC binary and run it.
There were utilities to compress executables that deleted the versions not for the current CPU - very handy in low-power 68Ks
This seems tragically the inevitable, but slow direction. We can only hope that it accelerates the transition of app stores to state-regulated markets rather than private arbitary fiefdoms.
I put "successfully" in quotes because MacOS in that era was notoriously crashy-buggy.
Not to diminish Apple's accomplishment, which was indeed impressive, but a lot of this was because by that point, PowerPC was so, so far behind Intel's chips that, even after the emulation performance penalty, the Core 2 chips were fast enough to make it no big deal.
There's not a similar Intel/ARM gap this time around so Microsoft will have to rely on their chops alone.
I think that Office version already is native, and that they gamble/expect that the likes of Photoshop and Mathematica will soon ship real native versions (rightfully so, as that is what happened when Apple jumped PC architectures, too, with the exception of Quark Express, which consequently got eaten by InDesign.)
4. Are there any plans on supporting Arm v7 in the future, e.g. with Surface/Surface 2 support?
Also, I have a bizspark Azure subscription and it's not a perfect UX; but man does it beat AWS
I actually disagree with this pretty strongly. The Azure UI seems flashy for the sake of being flashy. The AWS UI is much easier to navigate and use for me.
Azure's UI is more unified though. There are some random AWS services (e.g. sqs) that have a totally different UI theme going on.
Edit: the Azure UI is only more unified if you ignore the fact that there are two totally separate versions (classic + the new portal), and you end up having to hop between the two in some instances if you have some older infrastructure because feature parity is not perfect.
How so?
On AWS I was through a sea of services I don't need w/ poor docs, clunky configs and a lot of security tiers. Their pricing is baffling and I really just think it looks terrible. Azure has similar issues; but I can navigate it better and feel more comfortable w) it
http://blog.mcchristie.com/wp-content/uploads/insights-brick...
Microsoft has chosen to drop a lot of older models from the Creator's Update, but is still providing cumulative/security updates to the Anniversary Update right now, which is supported on all phones which run Windows 10 Mobile.
At least, at present, if you have a Windows 10 Mobile device, you have recent security updates, regardless of make or model.
(Although I'm in the UK, where the carriers are less abusive)
Worse yet if the update fails...
I assume they will be releasing a build configuration for native ARM software deployment on Windows.
It feels like microsoft these days think that people who make desktop apps and don't sell them in the store are robbing them.
Microsoft just needs the library of legacy Win32 apps to get their Windows-on-arm to take off, but they want as much as possible of new apps to be using the store. Not least evident by the new "The app you are installing is not from the windows store" messages in Creators Update.
Edit: Apparently Surface 2 isn't AArch64, so probably not.
(1) Microsoft makes generic install media available (rather than just device-specific restore media, for devices that ship with Windows 10 ARM), and
(2) Windows 10 ARM will run on ARMv7 devices, rather than being restricted to ARMv8 (AArch64) devices.
Imagine the motherboard on your phone, but in your laptop. The rest of the space would be used for batteries.
I personally see the much larger performance regression for Windows 10 on RPi3 in the fact that at least on Windows 10 IoT Core there was no hardware acceleration of graphics on RPi3 when I last tested it (about a year ago), which caused it to feel rather sluggish.
The macOS development stack has been re-tooled to output LLVM bitcode within its "fat" binaries for a good while now. It'd be very simple for Apple to throw the switch on a compile farm ala the one Google has for Android APKs, and suddenly have ARM downloads for everything on the Mac App Store (without requiring any re-submissions.) Which means it wouldn't be hard at all for Apple to ship a "functional" ARM macOS computer... just, until now, such a machine wouldn't have had a very good Windows story. No Boot Camp, no cheap virtualization, etc.
Suddenly, that story is a solved problem.
Yes, you could do the same thing with a plain x86-ISA binary, but such a binary might have sections that are very hard to transpile efficiently/effectively—because e.g. they exist as the result of compiling hand-optimized x86 ASM source modules. Targeting bitcode constrains the inputs a bit more, such that the input to the transpiler won't be using extremely-microarchitecture-specific instructions.
And yes, the results wouldn't be 100% efficient. But it would be efficient enough—like Rosetta—to serve as an effective stop-gap to allow ecosystem consumers to continue to consume their purchased apps on new devices, until ecosystem developers upload explicitly re-optimized apps. (And it would—like Rosetta—at least let apps from "dead" development studios run, rather than killing them off entirely.)
However you are forgetting three very important points:
1 - Apple is free to use their own fork of LLVM bitcode
2 - Apple controls what those bitcodes actually mean on their compiler stack
3 - LLVM guys already had a few talks at LLVM conferences about creating an actual platform independent form of bitcode
Intel shot itself in the foot by replacing the Core architecture in mobile Celerons and Pentiums with Atom, and also by starting to rename lower performance Core M chips to Core i3 and Core i5. This will make it easier for ARM and AMD to "catch-up" and even beat Intel at these levels, because Intel got greedy and tried to trick the market with lower-performing chips at the same price points as for previous (and more powerful) generations.
Core mobile Celeron and Pentium are still available, for example Celeron 3865U [1], it's just Intel got tired of having names with useful information in them. That processor should probably have a name like Core v7 2C-2T 1.8Ghz-15W which has most of the useful information, but 3865U is what we got, so you have to filter out the atom chips yourself.
[1] https://ark.intel.com/products/96507/Intel-Celeron-Processor...
But when it comes to hardcore system software development stuff. They are unbeatable. Emulating entire x86 on ARM? This is mind blowing.
They have pulled good emulation before too (one I think was inside XBOX).
But this is going to be serious. I would say very serious.
Extremely good battery life would give Microsoft, very good edge over Apple.
1) Qualcomm will be the winner. and so other ARM CPU manufacturer. and Intel is the biggest loser here.
2) Microsoft will hit market with this. After this they will have extremely good position to release good phone, and here we stand, I see successful future for Windows Phone.
3) From Computer Architecture perspective, the bottleneck is not memory or CPU speed. It is IO and energy. I don't know how this will impact on IO. But I am almost sure this is unbeatable from energy efficiency, and when I (and almost all people I know) buying a laptop. battery life is almost the most important aspect of it.
(2) There's no reason why Samsung or one of the Chinese manufacturers couldn't make a Windows 10 phablet. Microsoft made Windows free on small-screen devices, so I assume it will continue to be free, or at worst, "zero paid".
[Microsoft had a Windows offering where OEMs paid $10 for the OS but got a $10 rebate for setting Bing as the default search engine. So technically, Windows wasn't free, but OEMs didn't pay anything to use it.]
Yes, Qualcomm was "established", but few would've thought Intel can't at least beat lesser known competitors such as MediaTek. It couldn't because Atom chips and Intel's cost structures in general are much higher than those of ARM chip makers - to the point where it prohibits Intel from competing head-on with ARM chip makers. Intel invested at least $10-$15 billion in the mobile market, and it only had 2% market share to show for it at the end. You can't even blame LTE modem technology for it, because Intel actually had better LTE tech than MediaTek, second only to Qualcomm. If anything, it should've helped Intel become Qualcomm's main competitor.
For now, we'll only see competition between ARM chips and Intel chips in budget laptops (which happen to be the most popular type of laptops), but with Moore's Law dying and Intel hitting a ceiling on performance/core, there's no reason why ARM chips can't catch-up to Intel at the higher-end levels of performance, too.
And don't forget that right now ARM chip makers are still building first for smartphones. That means they try to have a 4-5W TDP for the entire SoC at most. They haven't even tried to build a chip that has 15W, 30W or 45W TDP for a laptop. But if things go well enough for them in budget laptops, I could see them start building those types of chips, too.
This is also MediaTek's story in the mobile market. It started out competing with Qualcomm only in $100 smartphones with low-cost chips, and now it has just announced a 10nm high-end chip (Helio X30) that will compete against Snapdragon 835. It may not be quite as good still, but it should be close enough (the closest MediaTek has gotten, in fact). I imagine Microsoft will begin supporting that chip (or its successors) in Windows 10 soon enough, too.
Embedded devices, yes, but ARM on servers is more like ARM's perpetual future.
Everything old is new again!
I wonder if this ends up being the inheritor of Windows CE for embedded ARM-flavoured devices. I also wonder if this means that the Win10 ARM kernel has the full Windows API - so if you built an ARM PE executable that could run natively. I suspect 95% of the pieces are in place for that but it's not yet been productised.
Killing Windows RT was the right choice, because it was never designed to do something like this. It had a weak translation layer for Win32's API built right in, and they would have needed to do some wizardry to have the two live side by side. No, I think RT was a useful but failed experiment, and I'm excited to see them take this approach with Win32 emulation on ARM. If it works as well as these demos suggest it does, it could finally provide a good path for ARM into consumer laptops and even desktops, to spark some great competition in the space. I'm excited to see where this goes.
Mobile data collection tools on iOS and android devices are rather poor (at least open source ones), hopefully this will help solve this problem—we'll just be able to use windows applications that work and are better developed. The windows ecosystem still seems easier to me than iOS / Android, perhaps that's just my bias or that I see more development options.
This could be a huge turning point for Microsoft's mobile divisions.
x86 drivers are still something I'm curious about here...
[edit: I should also mention, the reason why geospatial tools comes into play here is because the snapdragon CPUs have integrated GSM and GNSS (GPS) on the die. Currently, x86 based tablets have to use a separate component, and many don't come with it or even provide GNSS as an option]
I can see a potential milestone Windows 10 S on an Arm V8 based laptop with all day battery+. Sort of a Surface RT but without any excuses.
If Apple follows suit and creates a light weight, network centric laptop experience around iOS, then you'll have three contenders for the 'appliance' environment, ChromeOS, Windows 10 S, and iOS. Each with their own 'laptop' design ethic, Pixel, Surface, MacBook.
Consequently, all this ARM talk has got to be making Intel nervous. I don't think now would be the best time to buy any INTC stock. :/
-- ST boot sector guy
EDIT: no [1].
[1] https://www.theverge.com/2016/12/7/13866936/microsoft-window...
http://i.imgur.com/mRdk6ZD.jpg
This is an ancient chip, however I also found MediaTek ones for ~ $10, which had 4 cores and were 1.6ghz SoC.
Sounds to me like we could seriously see $100 laptops that actually function soon.
They're essentially supporting the end result, I would hope they don't force developers to go through emulation to try to encourage them to write a universal windows app
