
Microsoft planning to enable x86 on ARM64 emulation in Windows 10 by Fall 2017 - benologist
http://www.zdnet.com/article/microsofts-x86-on-arm64-emulation-a-windows-10-redstone-3-fall-2017-deliverable/#ftag=RSSbaffb68
======
matt_wulfeck
> _Continuum -- the capability that will allow Windows 10 Mobile devices to
> connect to external displays and keyboards -- is going to be a key for the
> company_

This actually sounds like a very good move by Microsoft. Just issue people a
phone and they will do all their work on that. There's really no need for
giant workstations anymore, and I think this will be more successful than a
Chromebook-type thing.

~~~
adwn
> _There 's really no need for giant workstations anymore, and I think this
> will be more successful than a Chromebook-type thing._

What you meant to say was: _You_ don't need giant workstations anymore. There
are still plenty of people doing demanding work on their computers.

~~~
fit2rule
It is reasonable to assume that the vast majority of the worlds computers are
over-powered for the current set of users sitting in front of them.

~~~
elcct
I disagree. Most consumer computers are so slow you want to pull your hairs
out whilst waiting forever for something to load.

~~~
Tarean
I think for many that is a hard drive thing combined with dozens of tool bars,
though. Phones have solid state memory so that shouldn't be a major problem.

~~~
izacus
The solid state memory in phones is a far cry from anything in your computer
though and we regularly see devices with storage that's noticably slower than
even mechanical HDDs.

Think about flash storage on phones to be more in class of a fast SD card, not
the SATA3 SSD in your laptop.

------
glandium
Anyone else reminded of FX!32 on Windows NT for Alpha?
[https://en.wikipedia.org/wiki/FX!32](https://en.wikipedia.org/wiki/FX!32)

~~~
mrbill
Or the built-in ability to run 16-bit DOS/Windows apps on NT4 running on MIPS
Magnum R4000. I had one for a while and it was rather nifty at the time...

And then, as you mention, FX!32 for running 32-bit apps (slowly) on NT/Alpha -
I had it running on a Multia for a while. Those were some fun tiny machines.

~~~
glandium
A friend had an EV5 (iirc), and performance wasn't too bad for the time. FX!32
was actually pretty fast all things considered.

~~~
mrbill
It would have been interesting to see how the QuickTransit[1] tech would have
evolved, had IBM not bought and basically killed it.

Apple used it (as "Rosetta") to run PPC binaries on x86, but it supported
other CPU architectures, both as emulated platform and native targets.

[1]
[https://en.wikipedia.org/wiki/QuickTransit](https://en.wikipedia.org/wiki/QuickTransit)

------
haberman
> He noted that this technology seemingly has a new name, "CHPE." [...] My
> guess is the HP here is HP, as HP has been working increasingly closely with
> Microsoft on its Windows 10 PCs and the HP Elite x3 Windows Phone. (Maybe
> the "E" is for emulation?)

The binary file format on Windows is called PE (portable executable). I wonder
if this might possibly be a fat binary format.

~~~
problems
They wouldn't need to change the binary format for emulation though. It may be
something more like "universal" executables from OS X when they went to x86
though?

~~~
groovy2shoes
That's what a "fat binary" is :)

------
TazeTSchnitzel
Before someone says WOW64 isn't an emulator, the article isn't actually wrong.
“64-bit Windows” originally meant Itanium, and WOW64 was an emulator on that
platform. Of course, it isn't (very much of one?) on AMD64.

~~~
sigjuice
Microsoft says it themselves and who are we to disagree?
[https://msdn.microsoft.com/en-
us/library/windows/desktop/aa3...](https://msdn.microsoft.com/en-
us/library/windows/desktop/aa384249\(v=vs.85\).aspx)

"WOW64 is the x86 emulator that allows 32-bit Windows-based applications to
run seamlessly on 64-bit Windows".

~~~
i336_
"Wine Is Not an Emulator" -> WINE

"WINdows Emulator" -> WINE

I've seen both interpretations be used.

In this case, "minimal hypervisor and address space translation layer" (more
or less - I've no idea exactly what it does) is somewhat harder to remember.

I think they were going for "simplest/shortest word that gets the point
across" since that document is likely to be read by people leaning more toward
executive/high-level positions as opposed to the detail-jugglers who shout at
bare metal all day.

~~~
0x0
Address space translation is not a small thing to do in the win32 API. Not
only do you need to translate pointer parameters and return values for
thousands of API function calls, you also need to translate pointers in
(possibly nested) structures, and also to do the same for each and every
possible window message, where the general message payload may be any one of a
combination of integers, pointers, and structures of (structures of) pointers.
The pointers may be data pointers where the pointed-to object may be data such
as a string that needs to be readable and writable from either side of the
address space, or functions that can be called from either side.

See for example this effort at writing a win16 thunking layer in c#
[https://medium.com/@CantabileApp/implementing-window-
messagi...](https://medium.com/@CantabileApp/implementing-window-messaging-in-
win3mu-979a0ea31571#.x1njepxaz)

~~~
tinus_hn
Why would you do that? They can just include the 32-bit libraries.

Wine works by changing enough of the windows system that the libraries can
communicate with the host operating system.

Microsoft already has the 32-bit libraries, 'all' they have to do is make sure
the parts of the libraries that interface with the rest of the system do the
translation, which is much less work and a reasonably well defined edge.

------
mmastrac
How awesome would it be if we could have a PnP processor? If you are docked,
you run native x86 code. If you are mobile, you emulate it. The
docking/undocking process could even be similar to VMotion.

~~~
Analemma_
It's a cool idea, but wouldn't the CPU be awfully far from the cache and RAM
if you did that? You could put some RAM in the docking station with the x86
chip, but at that point you're two-thirds of the way toward just having
another computer in there, which kind of defeats the purpose.

~~~
mmastrac
I agree, it would probably be necessary for _everything_ to live in the
docking station other than storage. You'd basically be transferring the live
system state, which would then take over from the portable device.

The idea here is that you can "convert" your mobile device into a powerful
desktop, though in reality you are just moving the current, live state from
mobile to desktop.

~~~
bhauer
That is what some people have conjectured is in the works with a "Surface
Phone," although it's really anyone's guess at this point. But it certainly is
very appealing. With this new emulation news, the use-case could be that you
can run your x86 apps (slowly) in a pinch while out and about. When you get
home or to the office, you dock up to get a full-powered PC experience.

------
webaholic
Please note that you can kind of already do this using qemu on both windows
and linux.

~~~
lunixbochs
You can do this in the 99% case on Linux using qemu-user, but I'm not aware of
an equivalent for Windows (and booting an entire operating system in an
emulator is a poor experience and will be even slower). I imagine this Windows
variant works like qemu-user and Rosetta.

QEMU has some bad performance penalties, I think partially related to the
generic JIT (TCG), extremely strict floating point, and full host memory
isolation. ExaGear is significantly closer to native performance but I think
only supports emulating 32-bit x86.

~~~
zeta0134
This is a trade-off with any emulation really. The more hardware accurate your
emulation gets, the more you have to keep track of in virtual registers and
state, and all that extra tracking adds up in a hurry.

Native virtualization dodges a lot of that performance penalty by using the
hardware features directly where possible. But that's only really feasible on
systems that have nearly identical hardware; x86 is pretty standardized at
this point and virtualizes quite well. ARM is much more varied and harder to
virtualize, even on other ARM platforms due to differing feature sets.

~~~
lgeek
It's not that in this case, this is plain binary translation and not cycle
accurate emulation. QEMU is super slow on x-to-x translation as well
(something like 8x to 80x slowdown). Its translator is inefficient (for the
sake of portability, the source native code is first translated to an IR and
then the IR is compiled to target native code with limited optimisation) and
it emulates all floating point instructions in software.

~~~
john_reel
How does it handle polymorphic code?

------
wfunction
How would this actually work? Wouldn't it be painfully slow? Even ARM
emulation on x86 seems to be pushing it, and I feel like the reverse should be
10x worse at best...

~~~
wvenable
Given the entire OS would still be native, it might not be too bad for certain
classes of applications. You would expect games to perform terribly but
standard corporate desktop applications would probably perform pretty well.

Many of our critical corporate applications were designed a decade ago -- so
you just have to emulate the average desktop performance from those days.

~~~
Havoc
>standard corporate desktop applications would probably perform pretty well.

Don't say such evil things.

Spend half my days being frustrated by corporate software. .net software that
runs on a modern i7 ultrabook with SSD. Doesn't do anything wild (mostly
buttons & menus)...yet its bloody slow. HOW???

~~~
youdounderstand
Undoubtedly due to blocking the UI thread on I/O.

~~~
i336_
Or an overabundance of I/O.

A friend showed me the industry-standard database app used to manage most
Internet-connected second-hand bookshops (I think).

Its development decisions went something like:

"Hey, let's be sooooo awesome and update the search results live, as you type!
Wow, without even a one-second delay this is SO REALTIME - like we're in 2187"

(later)

"Do we need to index the database? ...eh, nah. I don't think our custom
database solution even supports indexing. Kay."

In my friend's case the store he's at has _tens of thousands of books_.

 _Cue perpetual SSD replacements by all the shops using this software_

My approach to using it (when my friend and I were discussing it while I
visited) was to hit Win+R to obtain a text box, type my search string, then
^C/ESC/^V it over. The database app would lock up for about 1.2 seconds per
keypress.

~~~
nine_k
Acceptance testing? Load testing? No, never heard of those :-/

------
dynjo
This may play very well for Apple also if they intend to move to ARM CPUs in
MacBooks. Bootcamp would have been a major blocker.

------
nixos
My question is how would this affect the market?

Apple will stay Apple. I don't think they'll go anywhere.

The question is Google. If this happened in 2008, I don't think Android would
have taken off anywhere close to the way it did.

But now? One one hand, Android has millions of apps already on the market. On
the other hand, Microsoft now has potentially millions of old, existing,
applications.

I don't think it will make a dent in the phone market. It's too commonly used
as a hand-held rather than a station, and windows apps are useless there.

On the other hand, it can tank the Android tablet market

~~~
KMag
I agree on the phone side. How many of those millions of apps are usable from
a phone screen, using a phone interface? This sounds like cool technology, but
this particular use case sounds very limited use on phones.

However, on the tablet side, it may allow Microsoft to bring down the price of
the Surface a bit while still maintaining legacy app compatibility.

My understanding is that Intel caught up with ARM a couple years ago on
performance-per-Watt, but how's the idle power consumption of 64-bit Atom
processors these days compared to 64-bit ARM offerings? For many consumer use
cases, idle power consumption has a bigger impact on battery life than does
performance-per-Watt.

I'm a bit sad this news came out after SoftBank bought up my ARM shares, but
I'm glad to see more evidence we may yet get the x86 monkey off our back.

------
aq3cn
SoC like Lattepanda can run full version of Windows. I speculate that flagship
phones by MS will have Intel chip in it, so no need of emulation. Evan Blass
also Tweeted that we may see Intel chip in our phone in near future.

But anyway, this emulation will be helpful for cheaper phones. I am holding my
breath for that day.

[https://twitter.com/evleaks/status/794598340927307777/photo/...](https://twitter.com/evleaks/status/794598340927307777/photo/1)

~~~
masklinn
> SoC like Lattepanda can run full version of Windows. I speculate that
> flagship phones by MS will have Intel chip in it

LattePanda demands a 10W power supply (5V@2W), good luck getting that in a
phone.

------
weitzj
I guess this is the same reason HyperKit exists for macOS. So Apple can switch
to Arm for Desktop or run iOS Apps on macOS. But I still don't get how BitCode
fits into this. It seems like 2 separate teams at Apple had to tackle the
problem on how to run apps on different architectures. One solution is
BitCode, the other HyperKit, which would be used like a new Rosetta (PowerPC
-> x86), but from (x86 -> arm64)

------
mtgx
Long overdue, but still welcome. Intel direly needs the competition. With AMD
Zen and ARM notebooks coming, hopefully the market will look much more
competitive in 2018.

Also, maybe Microsoft will have the guts to do what Google never did:
standardize ARM processors, so that all ARM devices can be updated at once.
Although I assume Microsoft will also start by supporting "Qualcomm-only" at
first, just like it did for phones.

~~~
B1FF_PSUVM
> Intel direly needs the competition

They're already heading for the hills - this just adds to the swamping they're
getting in the low ground ...

------
whitehat2k9
What are the performance implications of this? Isn't cross-instruction set
emulation typically associated with substantial performance hits?

------
markingram
Would this impact HoloLens? I am so in love with it, and how can you not be,
just look at this...
[https://www.youtube.com/watch?v=6vjlXJCcUUc](https://www.youtube.com/watch?v=6vjlXJCcUUc)

~~~
ausimian
Hololens already runs x86 natively. What did you have in mind?

------
jaxondu
Remind me Microsoft is on a Frankenstein streaks lately, merging tablet touch
with desktop, mixing Linux terminal inside Windows and this.

------
cordite
Will we start seeing "Universal" apps on windows too, as in the fat binaries
which have multiple architectures compiled into one?

~~~
msbarnett
pe/coff doesn't support anything like mach-o's nfat_arch header/fat_arch
structs, so it's unlikely

~~~
DHowett
FWIW, neither did Mach-O in the beginning; the fat magic and fat_arch structs
are bolted onto an archive of single-architecture binaries, and they debuted
in 2005.

~~~
msbarnett
Erm, in Mach-O it dates back at least to the OpenSTEP multi-architecture
support, which was early-to-mid 1990s?

------
raverbashing
I wonder if the objective is only mobile devices or also the server market

~~~
cptskippy
The article cites Windows 10 so I suspect it's primarily Mobile and
potentially IoT. That doesn't mean some flavor of it won't make it into
Windows Server but currently the don't ship an ARM flavor of Server. If we saw
ARM support in Server it probably wouldn't be until 2020 since Microsoft isn't
known for making sweeping changes with their r2 release and 2016 just shipped.

------
novaleaf
mojang? could someone please inform me how it's related? (mentioned in the
article that this tech comes from mojang, the makers of Minecraft (?!?!?!))

~~~
lloydsparkes
The code name is all that's related to Mojang

Microsoft has used a number of minecraft terms as codenames.

RedStone Cobalt

