Linked by Thom Holwerda on Mon 12th Jun 2017 20:31 UTC, submitted by dionicio
Intel

You'd expect with Microsoft adding x86 emulation to its upcoming ARM-based windows 10 PCs all the possible licensing issues would be sorted. As ubiquitous as x86 is, it's easy to forget it's still a patent minefield guarded by Intel. And surprise, surprise, with the chipmaker under pressure from AMD and ARM, it felt the need to make that very, very clear. Dangling at the end of a celebratory PR blog post about 40 years of x86, Intel writes:

However, there have been reports that some companies may try to emulate Intel's proprietary x86 ISA without Intel's authorization. Emulation is not a new technology, and Transmeta was notably the last company to claim to have produced a compatible x86 processor using emulation ("code morphing") techniques. Intel enforced patents relating to SIMD instruction set enhancements against Transmeta's x86 implementation even though it used emulation. In any event, Transmeta was not commercially successful, and it exited the microprocessor business 10 years ago.

Only time will tell if new attempts to emulate Intel's x86 ISA will meet a different fate. Intel welcomes lawful competition, and we are confident that Intel's microprocessors, which have been specifically optimized to implement Intel's x86 ISA for almost four decades, will deliver amazing experiences, consistency across applications, and a full breadth of consumer offerings, full manageability and IT integration for the enterprise. However, we do not welcome unlawful infringement of our patents, and we fully expect other companies to continue to respect Intel's intellectual property rights. Strong intellectual property protections make it possible for Intel to continue to invest the enormous resources required to advance Intel's dynamic x86 ISA, and Intel will maintain its vigilance to protect its innovations and investments.

I'm assuming Microsoft has all this stuff licensed nice and proper, but it's interesting that Intel felt the need to emphasize this as strongly as they do here. Which companies is Intel referring to here? Maybe Apple?

Order by: Score:
Time to move on?
by sbenitezb on Mon 12th Jun 2017 20:50 UTC
sbenitezb
Member since:
2005-07-22

I hope the world starts moving to ARM.

Reply Score: 7

RE: Time to move on?
by Flatland_Spider on Mon 12th Jun 2017 21:14 UTC in reply to "Time to move on?"
Flatland_Spider Member since:
2006-09-01

A RISC-V world would be better.

Reply Score: 8

RE[2]: Time to move on?
by Kochise on Tue 13th Jun 2017 05:15 UTC in reply to "RE: Time to move on?"
Kochise Member since:
2006-03-03

MIPS, SH, 68K, there're other ISAs out there that worth a look at.

Reply Score: 3

RE[2]: Time to move on?
by moondevil on Tue 13th Jun 2017 07:47 UTC in reply to "RE: Time to move on?"
moondevil Member since:
2005-07-08

You mean Android like fragmentation at CPU level?

AFAIK only the RISC-V core is open.

Reply Score: 4

RE[3]: Time to move on?
by Kroc on Tue 13th Jun 2017 08:23 UTC in reply to "RE[2]: Time to move on?"
Kroc Member since:
2005-11-10

As if ARM isn't fragmented already? "ARM" is already a hodgepodge of different ISAs and whatever customisation the vendor throws in.

RISC-V would still be a step forward, whatever happens.

Reply Score: 3

RE[4]: Time to move on?
by Bill Shooter of Bul on Tue 13th Jun 2017 13:42 UTC in reply to "RE[3]: Time to move on?"
Bill Shooter of Bul Member since:
2006-07-14

Well, there has been an attempt to standardize arm for servers

https://github.com/ARM-software/sbsa-acs

The spec for that itself is arm customer only, but the compliance suite is open source, apparently.

Basically it says you have to use UEFI and ACPI which allows operating systems to know how to boot and how to discover and talk to random hardware.

Reply Score: 2

RE[5]: Time to move on?
by Andre on Wed 14th Jun 2017 09:25 UTC in reply to "RE[4]: Time to move on?"
Andre Member since:
2005-07-06

ACPI and UEFI? Isn't a device tree the more common way to communicate the hardware information to a kernel on ARM?

Reply Score: 1

RE[6]: Time to move on?
by sarreq on Thu 15th Jun 2017 13:06 UTC in reply to "RE[5]: Time to move on?"
sarreq Member since:
2010-03-14

Yes, but you have to compile from the device tree for each system you install on. with a UEFI and ACPI, you can use plug-and-play to install drivers on the fly.

Reply Score: 1

RE[7]: Time to move on?
by Andre on Thu 15th Jun 2017 14:18 UTC in reply to "RE[6]: Time to move on?"
Andre Member since:
2005-07-06

UEFI and ACPI won't magically know the device configuration either. ACPI tables will have to be compiled too for each device.

Changing the bootloader protocol, how the information is passed to the kernel, does not change the fact the information has to come from somewhere.

Reply Score: 1

RE[3]: Time to move on?
by tylerdurden on Tue 13th Jun 2017 22:36 UTC in reply to "RE[2]: Time to move on?"
tylerdurden Member since:
2009-03-17

Yup. RISC-V and SPARC are just about the only mainstream ISAs without legal minefields attached to them.


I don't think either MS or Qualcomm have much to worry about here. They're not replicating any of the uarch stuff that is what's patentable.

It probably will fall into some sort of copyright issue, but I doubt Intel can forbid anything having to do with binary code they haven't produced, even if it uses their ISA.

If anything the bigger issue is the power efficiency of the emulation, rather than Intel's FUD.

Edited 2017-06-13 22:40 UTC

Reply Score: 3

RE: Time to move on?
by Adurbe on Tue 13th Jun 2017 08:11 UTC in reply to "Time to move on?"
Adurbe Member since:
2005-07-06

Wouldn't that move you from one patent minefield to another? Make no mistake, ARM is as well protected as intel, thy just let other people manufacture.. right now.

Reply Score: 2

RE: Time to move on?
by tylerdurden on Tue 13th Jun 2017 22:32 UTC in reply to "Time to move on?"
tylerdurden Member since:
2009-03-17

We should jump out of the frying pan, the flames are much better!

Reply Score: 2

RE: Time to move on?
by Megol on Wed 14th Jun 2017 19:14 UTC in reply to "Time to move on?"
Megol Member since:
2011-04-11

I hope the world starts moving to ARM.


ARMv2 at least isn't patented anymore. Anything newer is potentially or guaranteed littered with patents from a company that will aggressively defend anything patent related. And they have resources to sue anyone they want.

RISC-V is a better choice though it isn't really innovative (not a real problem).

Reply Score: 2

Dangerous ground
by Alfman on Mon 12th Jun 2017 21:00 UTC
Alfman
Member since:
2011-01-28

I'm assuming Microsoft has all this stuff licensed nice and proper, but it's interesting that Intel felt the need to emphasize this as strongly as they do here. Which companies is Intel referring to here? Maybe Apple?


Intel must realize it's on dangerous ground here. Legally speaking they could find a court willing to block competing x86 implementations, but they will likely loose favor in the public eye if they start pursuing unpopular patent infringement lawsuits over x86 emulation. IMHO intel should stay focused on their advantages instead and invest that money in making their CPUs better.

Reply Score: 3

RE: Dangerous ground
by dionicio on Mon 12th Jun 2017 21:18 UTC in reply to "Dangerous ground"
dionicio Member since:
2006-07-12

Can't remember where I read It, but seems you can't demand wherever you like, anymore.

Reply Score: 2

RE[2]: Dangerous ground
by Drumhellar on Wed 14th Jun 2017 19:00 UTC in reply to "RE: Dangerous ground"
Drumhellar Member since:
2005-07-12
RE: Dangerous ground
by acobar on Mon 12th Jun 2017 23:08 UTC in reply to "Dangerous ground"
acobar Member since:
2005-11-15

From what I have been reading, it is not the x86 original/base instructions set but the current and way newer SIMD (SSE), VT and other extensions that are really the reason to worry. Not sure though.

Granted, if you don´t have a way to emulate these new tech, specially on-core, you are going to suffer from performance and usability.

I think the real target of Intel comments are the other hardware designers, not Microsoft, primarily.

Reply Score: 2

RE[2]: Dangerous ground
by Kochise on Tue 13th Jun 2017 05:18 UTC in reply to "RE: Dangerous ground"
Kochise Member since:
2006-03-03

...make it possible for Intel to continue to invest the enormous resources required to advance Intel's dynamic x86 ISA...

Sure, such improvement, SSE, SSE2, SSE3, SSSE3, SSE4, SSE5, ... Iterative "improvements" to reset patent watchdog at regular intervals. Clock is tickling at metronomic rate.

Reply Score: 3

RE: Dangerous ground
by Carewolf on Tue 13th Jun 2017 14:38 UTC in reply to "Dangerous ground"
Carewolf Member since:
2005-09-08

Also they can't block implementations of the ABI, just for being the same ABI. Only for using the patented techniques.

Reply Score: 2

What about VirtualBox, then?
by xristos on Mon 12th Jun 2017 21:43 UTC
xristos
Member since:
2014-04-25

Would they need to get a license from Intel?
(do they already have one?)

Reply Score: 1

RE: What about VirtualBox, then?
by galvanash on Mon 12th Jun 2017 22:09 UTC in reply to "What about VirtualBox, then?"
galvanash Member since:
2006-01-25

Virtualbox is not an emulator... It is virtualization.

x86 Emulators (like Bochs) actually emulate the entire processor, as such they have to actually implement instruction decoding, execution, and what not (things the patents that Intel holds apply to). Bochs would technically need a license, but there is no money behind it so Intel seemingly doesn't bother to threaten them.

Virtualization does not do that. When you run stuff on Virtualbox your just running native x86 code directly on the underlying processor. Virtualbox emulates I/O devices, or more accurately proxies access to them so that the virtualized environment thinks it has its own dedicated I/O devices. It more or less acts as a traffic cop, marshaling access to the devices that need to be proxied. There is very little "emulation" involved with it (other than the device drivers themselves).

Intel doesn't require patent licenses for such software - they actually encourage use of virtualization - because you need an x86 processor to run it on...

Edited 2017-06-12 22:18 UTC

Reply Score: 5

kurkosdr Member since:
2011-04-11

Virtualbox is not an emulator... It is virtualization.

x86 Emulators (like Bochs) actually emulate the entire processor, as such they have to actually implement instruction decoding, execution, and what not (things the patents that Intel holds apply to). Bochs would technically need a license, but there is no money behind it so Intel seemingly doesn't bother to threaten them.


VirtualBox can emulate an x86 if you have VT-x disabled in the BIOS, I 've tried it. VMware couldn't.

Edited 2017-06-12 23:21 UTC

Reply Score: 3

Milan Kerslager Member since:
2009-11-20

VT-x is hardware (ie. CPU based) support for the virtualisation. Without VT-x you may still use software virtualisation based on i386 capabilities and this is just slow, but it works. It could be speeded up by modifications of the virtualised system, but it is impossible for Windows as you have no source code and Microsoft will do nothing to help you. .

Reply Score: 1

FlyingJester Member since:
2016-05-11

Are you sure that "software virtualization" isn't just, you know, emulation? Or is there actual dynamic recompilation happening?

Reply Score: 2

galvanash Member since:
2006-01-25

Are you sure that "software virtualization" isn't just, you know, emulation? Or is there actual dynamic recompilation happening?


There are various approaches, but in simple terms it is just trapping on all memory access instructions and rewriting the segment addresses in the instruction stream. Its an elaborate form of segmented mode + some privilege ring manipulation.

Call it what you will. I have heard the term binary translation used to describe it and that seems appropriate. I just think calling it emulation is a bit much...

Edited 2017-06-13 00:18 UTC

Reply Score: 3

FlyingJester Member since:
2016-05-11

Yeah, I would not call that emulation since the machine code runs on the host CPU, just with trapped instructions. Whether this happens beforehand with a recompilation (similar to a linker) or at runtime with traps is not so important.

Reply Score: 2

cb88 Member since:
2009-04-23

Why would you need to do dynamic recompilation on when running x86 on x86... you don't. You just need to trap hardware accesses and such.

Reply Score: 2

galvanash Member since:
2006-01-25

VirtualBox can emulate an x86 if you have VT-x disabled in the BIOS, I 've tried it. VMware couldn't.


Its still not full emulation, it just trap-and-handle on specific instructions and doing some fancy translation of the instruction stream (yes, oversimplified, but mostly accurate). Even with VT-x disabled, you are still passing the vast majority of instructions through to the CPU as is, your just doing fixups of specific instructions before they reach the CPU.

Most Virtualization software stopped supporting this approach ages ago. Even Virtualbox no longer supports it for 64-bit code (VT-x or AMD-V is required for 64-bit guest OS). Its mostly just left in there for people running 32-bit stuff on really old CPUs - VT extensions are significantly faster when available.

Reply Score: 3

Alfman Member since:
2011-01-28

kurkosdr,

VirtualBox can emulate an x86 if you have VT-x disabled in the BIOS, I 've tried it. VMware couldn't.



That's true, virtualbox can use software emulation or VT-x, although I don't believe it supports cross architecture emulation. Qemu does actually support cross architecture emulation: you can run x86 guests on a multitude of host architectures.

This project even dynamically translates x86 code to llvm:
http://infoscience.epfl.ch/record/149975/files/x86-llvm-translator-...
QEMU [1] is a system emulator that can run unmodified
guest operating systems on a host OS, where the guest
and host CPU architecture can be different. For example, QEMU can run x86 guest OSes on a MIPS host
...
We extend the QEMU dynamic binary translator to generate LLVM bitcode from x86 (Figure 2). The translator takes x86 code, disassembles it to micro-operations,
maps the micro-operations to their LLVM counterparts,
and outputs LLVM bitcode.


An interesting side effect of this is that because the recompiled code can be run through an optimizer, you could theoretically get even better performance under emulation than running the original code natively (the original compiler might not have been able to produce as highly optimized code as QEMU). This would be interesting to test in practice.



Back to the topic at hand though, I guess intel's just been turning a blind eye to x86 emulation. I wonder if they'll just go after microsoft x86 emulation or if they might seek to shut down projects like qemu as well.

Reply Score: 2

RE: What about VirtualBox, then?
by Brendan on Tue 13th Jun 2017 02:27 UTC in reply to "What about VirtualBox, then?"
Brendan Member since:
2005-11-16

Hi,

Would they need to get a license from Intel?
(do they already have one?)


No.

Software is very different to hardware, and (even for the "no VT-X" case) it's very unlikely that a software emulation will infringe Intel's hardware patents.

The problem here is that Qualcomm are doing/planning hardware emulation (and not software emulation), and therefore it's far more likely to infringe on Intel's hardware patents.

- Brendan

Reply Score: 3

RE[2]: What about VirtualBox, then?
by Alfman on Tue 13th Jun 2017 04:43 UTC in reply to "RE: What about VirtualBox, then?"
Alfman Member since:
2011-01-28

Brendan,

Software is very different to hardware, and (even for the "no VT-X" case) it's very unlikely that a software emulation will infringe Intel's hardware patents.


I'm less confident than you on this point, but I guess we can only speculate for now.


The problem here is that Qualcomm are doing/planning hardware emulation (and not software emulation), and therefore it's far more likely to infringe on Intel's hardware patents.



Microsoft's engineers specifically state that a software emulator is being used and the underlying qualcomm processors do not support x86 hardware emulation. The whole video is worth watching, but I'm highlighting these quotes:
https://channel9.msdn.com/events/Build/2017/P4171
1:00: These new windows 10 on arm will be powered by qualcomm snapdragon processors...

7:40: You have a CPU emulator, which traditionally on a normal 64bit PC runs in hardware, runs the 32bit code in hardware, but on arm we don't have that so we've implemented a dynamic binary translator which will look at chunks of code and at run time translate them to blocks of arm 64 code which will cache in memory or on disk for subsequent use.



Apparently only x86-32 emulation will be supported, which I find kind of odd. If this had been engineered from scratch, the lack of 64bit seems like an obvious omission. I get the distinct impression this limitation is a carryover from the emulator's origin. I'm thinking it's the same emulator microsoft used to run x86-32 code on IA64 (itanium). They took the existing emulator and ported it to ARM64. The IA64 x86 emulator never supported AMD's x86-64 extensions and x86-64 ended up replacing IA64.

They probably discussed using QEMU and it's full 64bit emulation, but then microsoft would have had to comply with the GPL.

Edited 2017-06-13 04:59 UTC

Reply Score: 3

Brendan Member since:
2005-11-16

Hi,

I'm less confident than you on this point, but I guess we can only speculate for now.


I heard "software emulation" before too; but if it was pure software emulation they'd be saying "works on any ARM64 from any vendor". They're not doing that, which tells me that there's some changes in Qualcomm processors specifically designed to assist with emulation.

Note that "changes to assist with emulation" could mean anything; like maybe adding an internal "parity flag" that's set by normal ARM instructions to make emulating the 80x86 EFLAGS faster, or adding new instructions where 80x86 has something ARM lacks, or completely redesigning the entire memory subsystem to honour "80x86 cache coherency rules".

Microsoft's engineers specifically state that a software emulator is being used and the underlying qualcomm processors do not support x86 hardware emulation.


They say that the underlying Qualcomm processors don't execute 80x86 code directly; but they don't say that there's no special support for x86 emulation at all.

Apparently only x86-32 emulation will be supported, which I find kind of odd. If this had been engineered from scratch, the lack of 64bit seems like an obvious omission.


I don't necessarily find that odd. Microsoft made various changes in preparation (e.g. not supporting inline assembly for 64-bit code in VisualStudio, the introduction of .NET, etc); and even without these it's likely that the developer is still around and can still publish a native ARM version. It's the older stuff (which is predominantly 32-bit) where the majority of the problem would be. It's also the older 32-bit stuff that isn't designed to need a modern/fast CPU.

I also wouldn't assume that they'll never add support for 64-bit 80x86 code, and wouldn't assume that their emulator hasn't been designed to be adapted to 64-bit in future. It's normal to limit scope for the first release.

I get the distinct impression this limitation is a carryover from the emulator's origin. I'm thinking it's the same emulator microsoft used to run x86-32 code on IA64 (itanium). They took the existing emulator and ported it to ARM64. The IA64 x86 emulator never supported AMD's x86-64 extensions and x86-64 ended up replacing IA64.

They probably discussed using QEMU and it's full 64bit emulation, but then microsoft would have had to comply with the GPL.


The idea would be to translate blocks of 80x86 code directly into efficient equivalent blocks of ARM code. This means that the only part they'd be able to take from a previous "80x86 on Itanium" emulator is the front-end (decoding, etc) without any of the back-end (optimisation, instruction selection, etc).

Note that I doubt they would've considered Qemu. Its software emulation mostly just stitches together compiler generated snippets; which is far more portable, but wouldn't be anywhere near acceptable for performance.

As a random estimate, binary translation done well should be about 90% of the speed of native code (and Qemu's software emulation is only about 15% of the speed of native code, even for "80x86 guest on 80x86 host"). Also, don't forget that these Qualcomm CPUs are at a performance disadvantage already (e.g. 1.5 GHz Qualcomm vs. 3.5 Ghz Intel), so they can't afford too much "emulation overhead" on top of that.

- Brendan

Reply Score: 2

Alfman Member since:
2011-01-28

Brendan,

I heard "software emulation" before too; but if it was pure software emulation they'd be saying "works on any ARM64 from any vendor". They're not doing that, which tells me that there's some changes in Qualcomm processors specifically designed to assist with emulation.

Note that "changes to assist with emulation" could mean anything; like maybe adding an internal "parity flag" that's set by normal ARM instructions to make emulating the 80x86 EFLAGS faster, or adding new instructions where 80x86 has something ARM lacks, or completely redesigning the entire memory subsystem to honour "80x86 cache coherency rules".


I still believe what the engineers said in the video, that it is software emulation and I suspect qualcomm is merely the ARM64 vendor microsoft picked rather than windows being dependent on them. Do you have any source that would confirm microsoft is relying on qualcomm proprietary features?


The idea would be to translate blocks of 80x86 code directly into efficient equivalent blocks of ARM code. This means that the only part they'd be able to take from a previous "80x86 on Itanium" emulator is the front-end (decoding, etc) without any of the back-end (optimisation, instruction selection, etc).

Note that I doubt they would've considered Qemu. Its software emulation mostly just stitches together compiler generated snippets; which is far more portable, but wouldn't be anywhere near acceptable for performance.


What they described is how qemu works, and we don't know yet how fast microsoft's x86 emulator is going to be.


As a random estimate, binary translation done well should be about 90% of the speed of native code (and Qemu's software emulation is only about 15% of the speed of native code, even for "80x86 guest on 80x86 host"). Also, don't forget that these Qualcomm CPUs are at a performance disadvantage already (e.g. 1.5 GHz Qualcomm vs. 3.5 Ghz Intel), so they can't afford too much "emulation overhead" on top of that.


I think Qemu's software emulation (not VT-X) is actually better than that, I might run some benchmarks and get back to you. It's not like bochs where it has to emulate every cpu cycle and incur a significant overhead for it.

Reply Score: 2

Alfman Member since:
2011-01-28

Brendan,

As a random estimate, binary translation done well should be about 90% of the speed of native code (and Qemu's software emulation is only about 15% of the speed of native code, even for "80x86 guest on 80x86 host"). Also, don't forget that these Qualcomm CPUs are at a performance disadvantage already (e.g. 1.5 GHz Qualcomm vs. 3.5 Ghz Intel), so they can't afford too much "emulation overhead" on top of that.


I'll have to give you this one, I measured qemu's software emulation performance using sysbench, and its performance was 18% of native. I agree that software emulation run through an optimizer should be much better than this, but I guess qemu's software emulation hasn't received much attention with the advent of kvm. With kvm enabled it is 100%, which is not surprising.

It will definatly be interesting to see benchmarks of microsoft's x86 software emulation.

Just for comparison, itanium's x86 emulation back in the day had similar overhead.

https://tweakers.net/reviews/204/8/intel-itanium-sneak-preview-bench...

Reply Score: 2

Brendan Member since:
2005-11-16

Hi,

I still believe what the engineers said in the video, that it is software emulation and I suspect qualcomm is merely the ARM64 vendor microsoft picked rather than windows being dependent on them. Do you have any source that would confirm microsoft is relying on qualcomm proprietary features?


I don't have/can't find any proof that it's is "software emulation with hardware improvements to make it more efficient" and I also don't have/can't find proof that it's not.

What they described is how qemu works, and we don't know yet how fast microsoft's x86 emulator is going to be.


What they described is the general concept of binary translation; without mentioning any details of how it's implemented (e.g. and whether it's just stitching together snippets without any optimisation, or not).

However, the video did say something about caching "translated blocks" on disk; which (to me) suggests that they're not doing a "fast un-optimised translation" and are probably doing "slower optimised translation" (and want to cache it to avoid the overhead of optimisation next time).

- Brendan

Reply Score: 2

Alfman Member since:
2011-01-28

Brendan,

I don't have/can't find any proof that it's is "software emulation with hardware improvements to make it more efficient" and I also don't have/can't find proof that it's not.



Well, x86 acceleration would be extremely newsworthy, however everything I am seeing, including the video from microsoft's own engineers above indicates it's software emulation and not hardware accelerated. Even qualcomm's own specs for this processor doesn't have any mention of x86 acceleration, surely it would be relevant:

https://www.qualcomm.com/products/snapdragon/processors/835

https://www.qualcomm.com/news/onq/2017/01/03/meet-snapdragon-835-nex...

So I'll be happily surprised if there is hardware acceleration for x86, but I doubt it. We'll see soon enough what the benchmarks say, I'm definitely curious!

I'd love to have a good selection of ARM PC products capable of running both windows and linux, but I'm really afraid that these windows PCs on ARM64 will be vendor locked to microsoft. I hope I'm wrong ;)

Reply Score: 2

Brendan Member since:
2005-11-16

Hi,

Well, x86 acceleration would be extremely newsworthy, however everything I am seeing, including the video from microsoft's own engineers above indicates it's software emulation and not hardware accelerated. Even qualcomm's own specs for this processor doesn't have any mention of x86 acceleration, surely it would be relevant:


At one extreme there's "full hardware accelerated emulation", and at the opposite extreme there's "not even one minor tweak anywhere in the entire CPU to improve emulation performance"; and between these extremes there's a massive area of "changes that are not hardware accelerated emulation but exist to make software emulation easier/faster".

You are ignoring that massive area; which represents about 12345 billion smaller potential changes that wouldn't be newsworthy and wouldn't be mentioned in marketing material.

I'd love to have a good selection of ARM PC products capable of running both windows and linux, but I'm really afraid that these windows PCs on ARM64 will be vendor locked to microsoft. I hope I'm wrong ;)


For this I'd assume "UEFI Secure Boot" where other operating systems (e.g. Linux) can work fine as long as they're digitally signed with Microsoft's key.

- Brendan

Reply Score: 2

Drumhellar Member since:
2005-07-12

I heard "software emulation" before too; but if it was pure software emulation they'd be saying "works on any ARM64 from any vendor".


Not necessarily. They're trying to play up their relationship with Qualcomm for these new devices - they have no reason to mention support with other manufacturers while also talking up their new relationship with Qualcomm.

Reply Score: 2

Drumhellar Member since:
2005-07-12

Supporting 32-bit only code is probably how they're avoiding Intel's patents. Regular 32-bit x86 won't be covered by any patents anymore. x87 and MMX won't be, either, and patents on SSE will expire within a couple of years (If they haven't already - depends on when they were filed, but the first PIII came out in '99)

However, SSE2 patents are good for another few years, and AMD made SSE2 a mandatory part of x86-64, so emulating x86-64 means emulating SSE2, which could cause legal problems.

Reply Score: 5

The123king Member since:
2009-05-28

Maybe that's the reason Microsoft are only emulating X86-32

Reply Score: 2

Carewolf Member since:
2005-09-08

SSE2 patents are long expired. SSE4.1 and AVX patents though.

Reply Score: 1

Drumhellar Member since:
2005-07-12

SSE2 was first released in 2001, with the Pentium 4. unless they patented it before SSE was even released in 1999 (Very doubtful), we've still got a few years before SSE2 patents expire.

Remember: Patents last 20 years.

Reply Score: 2

viton Member since:
2005-08-09

Apparently only x86-32 emulation will be supported, which I find kind of odd.

There are strong technical reasons: performance and simplicity.
On 64 bit you can map entire 32-bit address space, so 'mov' instructions translate 1:1 to ARM instructions.

They probably discussed using QEMU and it's full 64bit emulation, but then microsoft would have had to comply with the GPL.

QEMU is an order of magnitude slower. This is not even an option

Edited 2017-06-13 09:00 UTC

Reply Score: 2

dionicio Member since:
2006-07-12

Other than microcode a favor to Intel, occupy ALWAYS LIMITED mind-real-state -a winning over competing architectures-.

But of course, not everyone within a Corp able to focus at the horizon.

IP exchange could be a way of avoiding Lawyer's Houses ruining a quick go forward.

Reply Score: 2

dionicio Member since:
2006-07-12

Cross licensing also.

Reply Score: 2

Apple
by Windows Sucks on Mon 12th Jun 2017 21:51 UTC
Windows Sucks
Member since:
2005-11-10

Not sure why it would apply to Apple as Apple moved to Intel and can move off just as easy. They don't need to emulate X86 to do it.

Only company talking about this is Qualcomm on ARM. They better watch out! Lol.

Reply Score: 2

RE: Apple
by bassbeast on Tue 13th Jun 2017 00:13 UTC in reply to "Apple"
bassbeast Member since:
2007-11-11

Because there has been serious talk of Apple using their own CPUs exclusively and using some sort of emulation to allow the X86 code to run for a limited time, similar to the fat binaries they had when they switched from PPC to X86.

You have to remember Cook was originally was in procurement, he knows how a single weakness in your supply chain can bone a company and the mess with Qualcomm I'm sure has driven that point home.

Reply Score: 3

RE[2]: Apple
by Richie97 on Tue 13th Jun 2017 04:29 UTC in reply to "RE: Apple"
Richie97 Member since:
2010-02-03

This came up a lot in 2011. And at the time many speculated on an x86 to arm version of Rosetta. Which seems to be what the speculation is here.

But apple abstracts the API much further these days. In fact Apple polices it's API much more aggressively that Microsoft. And according to many speculators, Apple has seen this coming for a long time. So it would not surprise me if any transition required minimal code alteration to compile for ARM. As most of the chip instruction set is abstracted away from the end user.

Reply Score: 1

RE[2]: Apple
by The123king on Tue 13th Jun 2017 08:48 UTC in reply to "RE: Apple"
The123king Member since:
2009-05-28

IMHO i think Apple should build a dual-architecture machine. By using a small ARM chip to handle the operating system overheads (such as memory management, drawing the UI etc) you'd be able to unload a lot of work from the Intel CPU, freeing it up for high performance workloads, such as video rendering and audio production. That way, you'll be able to max out the Intel core whilst keeping the OS slick and responsive. Of course, smaller low-performance apps, such as a browser, text editors etc could be compiled to run directly on the ARM core too, allowing the Intel cpu to be switched off if it's not in use by a high-performance app

Reply Score: 2

RE[3]: Apple
by sbenitezb on Tue 13th Jun 2017 14:17 UTC in reply to "RE[2]: Apple"
sbenitezb Member since:
2005-07-22

I think computers are already dual architecture, or even triple, as many SOCs include an ARM core taking care of low level stuff.

Reply Score: 2

Comment by galvanash
by galvanash on Mon 12th Jun 2017 22:00 UTC
galvanash
Member since:
2006-01-25

I'm assuming Microsoft has all this stuff licensed nice and proper


There is almost no way that is currently true. There was no announcement of any licensing agreement from Microsoft or Qualcomm, and considering they are basically giving this version of Windows away (and it is an outright threat to Intel's business model), there is no conceivable upside to compel Intel to offer licensing. In short, while it is possible, it is very unlikely.

Besides, historically Intel doesn't license anyone voluntarily (at least not in the last 20 years). Every holder of x86 patent licenses still enforcable got them through litigation settlements - which basically amounts to AMD and to a limited extent VIA and nVidia (the latter does not seemingly extend to x86 architecture though).

Everything else still in existence is either pre-MMX 32-bit x86 (upon which all relevant patents have expired), or blatantly ignoring them (Loongson, various open source products, etc.)

I'm fairly sure this press release was aimed directly at Microsoft and Qualcomm. Consider this a stern warning that Intel will respond legally if they feel the product violates their patents in any way, or alternatively opening to negotiations if Microsoft/Qualcomm are not 100% sure they are on safe legal ground (and be ready to pay through the nose)...

ps: It is entirely possible the x86 emulation they are planning does not violate Intel's patents. It depends on how far they go. 32-bit only x86 with no MMX/SSE/SSE2/FMA etc. extensions would conceivably be doable - because all of the relevant patents applicable to that have expired by now. Basic MMX might be possible as well, but it's debatable. Anything beyond that though and they are poking the bear. Maybe they got clever about it though, who knows.

Reply Score: 5

RE: Comment by galvanash
by avgalen on Tue 13th Jun 2017 11:47 UTC in reply to "Comment by galvanash"
avgalen Member since:
2010-09-23

This is the video that all the current info comes from:
https://sec.ch9.ms/ch9/77bc/0cb602d9-0828-49f9-a291-c17b26c377bc/P41...
(The demo-parts are from roughly 2:30 to 5:30 and around 12:00)

Basically they show that;
* Windows 10 Pro for ARM is a 64 bit OS that can run on 4 BIG and 4 LITTLE cores
* Because it is Pro you can also do things like a domain-join
* That OS runs natively and so do the build in store-apps
* Drivers for peripherals will be based on generic class drivers
* 7Zip (32 bit!!!!) can be installed just like on a normal 64 bit Intel machine and will end up in the c:\Program Files (x86)\7Zip folder (There was a previous demo of PhotoShop but no background/OS-info as far as I know, but I assume that was a 32bit PhotoShop as well)
* Store-apps and the store itself seem to be 32bit for reasons unknown to me but will run natively/compiled-for-ARM
* Most apps that are compiled for ARM should just work

The general idea about this "Windows on ARM" version is that it will be aimed, similar to Continuum, at light-and-portable devices where batterylife is more important than performance, just like the old Windows RT. However, where Windows RT failed because of an empty store, lack of hardware choice and no other software there is now a lightly filled store, there will be more hardware choice with much improved performance and there will be support for legacy 32bit applications.
"Windows on ARM" will not be meant for heavy gamers, video-encoding or servertasks!

Edited 2017-06-13 11:50 UTC

Reply Score: 4

RE: Comment by galvanash
by dionicio on Tue 13th Jun 2017 14:01 UTC in reply to "Comment by galvanash"
dionicio Member since:
2006-07-12

Thanks, Galvanash. Those are my memories, too. Hopeful those destructive behaviors doesn't replicate. The effort is on continuity, on legacy.

And that is a tribute to peace times. You can't go far, if having to start from the start line, every time.

Reply Score: 2

Comment by FlyingJester
by FlyingJester on Mon 12th Jun 2017 22:41 UTC
FlyingJester
Member since:
2016-05-11

Is AMD about to do something amazing that Intel caught wind of?

Reply Score: 3

RE: Comment by FlyingJester
by Carewolf on Tue 13th Jun 2017 14:47 UTC in reply to "Comment by FlyingJester"
Carewolf Member since:
2005-09-08

That would make sense, AMD and Intel has a cross license agreement, that is why AMD are allowed to make x86 processors and Intel are allowed to make x86-64 processors.

Reply Score: 2

Comment by kurkosdr
by kurkosdr on Mon 12th Jun 2017 23:24 UTC
kurkosdr
Member since:
2011-04-11

BTW, I am really eager to find out how far MS and Qualcomm are willing to go on that "running x86 code" thing. Now, don't get me wrong, I don't expect to boot Windows 7 on it, but will it be a full emulation of -say- the Pentium III ISA, or some "accelerator" thing helped by software?

Reply Score: 2

Comment by Sidux
by Sidux on Tue 13th Jun 2017 09:18 UTC
Sidux
Member since:
2015-03-10

Qualcom was announcing some interesting stuff due to be launched in Q2 2017 (like 48 core server chips on the new 10 nm design).
Looking at what AMD did with Ryzen, this can be a big hit for Intel in the data center land as well (where they also kept the focus some some years now).
Even on the software side things are moving slowly to ARM. Running x86 code is more like running legacy code these days.

Reply Score: 2

RE: Comment by Sidux
by dionicio on Tue 13th Jun 2017 14:19 UTC in reply to "Comment by Sidux"
dionicio Member since:
2006-07-12

They could slice the market: Intel up, ARM down, AMD middle grounds ;D </EndOfBabbling>

Reply Score: 2

Like Oracle/Google over Android
by FunkyELF on Tue 13th Jun 2017 18:52 UTC
FunkyELF
Member since:
2006-07-26

... just a couple more layers down.

Without arguing one way or the other about whether implementations should be patented, clearly specifications like the ISA should be treated like the Java API or .h files. Let anyone implement a compatible version. Good for competition.

License the name "Intel-compatible"

Reply Score: 2

RE: Like Oracle/Google over Android
by Alfman on Tue 13th Jun 2017 19:54 UTC in reply to "Like Oracle/Google over Android"
Alfman Member since:
2011-01-28

FunkyELF,


Without arguing one way or the other about whether implementations should be patented, clearly specifications like the ISA should be treated like the Java API or .h files. Let anyone implement a compatible version. Good for competition.


This case has gone back and forth in the courts it's hard to keep track of the events and reasoning.


"Google wins crucial API ruling, Oracle’s case decimated"
https://arstechnica.com/tech-policy/2012/05/google-wins-crucial-api-...

"Oracle wins copyright ruling against Google over Android"
http://www.reuters.com/article/us-oracle-google-ruling-idUSBREA480K...
The case examined whether computer language that connects programs - known as application programming interfaces, or APIs - can be copyrighted. At trial in San Francisco, Oracle said Google's Android trampled on its rights to the structure of 37 Java APIs.

U.S. District Judge William Alsup ruled that the Java APIs replicated by Google were not subject to copyright protection and were free for all to use. The Federal Circuit disagreed on Friday, ruled for Oracle and instructed the lower court to reinstate a jury's finding of infringement as to 37 Java API packages.
...
Programmers could still craft interoperable programs if the opinion stands, but lawyers will have to be more involved in signing off on what is permissible, said Eric Goldman, a professor at Santa Clara University School of Law.

"That's really expensive and lawyers are not going to give yes or no answers, and that's going to be stressful for everybody," Goldman said.


"Oracle denied new trial in copyright dispute with Google over Java"
http://www.pcworld.com/article/3125113/oracle-denied-new-trial-in-c...
A jury had cleared Google of copyright infringement in May this year, upholding the company’s stand that its use of 37 Java APIs (application programming interfaces) in its Android mobile operating system was fair use, thus denying Oracle up to US$9 billion in damages that it was seeking.


To be honest I didn't like the outcome because now courts have to apply the standards for copyright to APIs, in other words they are copyrightable in the US. This precedent means that we cannot assume APIs can be reimplemented without infringement, instead we must go to court to fight for a fair use exception on a case by case basis. Google's final case was a narrow win that only applied to google's case. This really sucks for software developers because APIs exist to serve a functional purpose rather than an expressive one and we can't know whether or not our re-implementing of an API will infringe - it will depend on the technicalities/judge/lawyers/etc.

Edited 2017-06-13 19:57 UTC

Reply Score: 2

Just so we are clear...
by cb88 on Tue 13th Jun 2017 22:25 UTC
cb88
Member since:
2009-04-23

The most important patents Intel had on x86 are all expired... AMD owns all the amd64 patents that matter, if some of Intel's SMID instruction sets dropped off the face of the earth noone would bat an eye....

Reply Score: 2

RE: Just so we are clear...
by tylerdurden on Wed 14th Jun 2017 01:29 UTC in reply to "Just so we are clear..."
tylerdurden Member since:
2009-03-17

You'd be surprised how much code depends on MMX/SSE/AVX instructions.

Reply Score: 2

RE[2]: Just so we are clear...
by Alfman on Wed 14th Jun 2017 03:22 UTC in reply to "RE: Just so we are clear..."
Alfman Member since:
2011-01-28

tylerdurden,

You'd be surprised how much code depends on MMX/SSE/AVX instructions.


For kicks, I ran the objconv disassembler against 32bit 7zip (this is significant because microsoft's x86 emulation demo specifically shows 7zip).
http://www.agner.org/optimize/#objconv

And sure enough it uses MMX, SSE2, and even the AES crypto instructions.
pxor
movdqa
paddq
aesdec
aesdeclast

It appears these instructions are only present in selected loops inside 7zip, so these code paths were probably optimized by hand.


chrome uses SSE1, SSE2 and SHA instructions
sha256rnds2
ucomisd
mulsd

These vector instructions are dispersed throughout the chrome code, suggesting the compiler flags were set to enable SSE auto-vectorization.


ekiga does not appear to use SSE

firefox uses SSE1, SSE2

vlc uses SSE2

putty does not appear to use SSE

teamviewer uses SSE1, SSE2 throughout code.

thunderbird uses SSE1, SSE2

...

This isn't very comprehensive but I think it's safe to say that a lot of 32bit windows software has been compiled to target SSE2 at least.

Reply Score: 2

RE[3]: Just so we are clear...
by galvanash on Wed 14th Jun 2017 04:51 UTC in reply to "RE[2]: Just so we are clear..."
galvanash Member since:
2006-01-25

And sure enough it uses MMX, SSE2, and even the AES crypto instructions.


I have no idea if this is the case or not, but just because the binary has those instructions in it does not mean that Microsoft's emulator supports executing them. The binary could have been compiled with alternate code paths for CPUs that don't have the correct feature flags - the instructions would still be in the binary, just dormant when run on CPUs not reporting support for them.

I could be totally wrong too, I don't know. If they are actually supporting and executing SSE2 and AES instructions in their emulator they are going out on a limb legally...

Edited 2017-06-14 04:54 UTC

Reply Score: 2

RE[4]: Just so we are clear...
by Alfman on Wed 14th Jun 2017 13:13 UTC in reply to "RE[3]: Just so we are clear..."
Alfman Member since:
2011-01-28

galvanash,

I have no idea if this is the case or not,


So my word's not good enough, haha, well it's easy enough to verify independently.

but just because the binary has those instructions in it does not mean that Microsoft's emulator supports executing them. The binary could have been compiled with alternate code paths for CPUs that don't have the correct feature flags - the instructions would still be in the binary, just dormant when run on CPUs not reporting support for them.


I agree it's possible those exist under conditional code paths, especially where the SSE code was hand optimized. However in cases where the compiler was configured to output SSE instruction throughout the code, it's really not common practice to provide both an SSE and non-SSE version of the code in this day and age since these go back even further than AMD64.

I could be totally wrong too, I don't know. If they are actually supporting and executing SSE2 and AES instructions in their emulator they are going out on a limb legally...


My "genuine intel" processors do not support AES/SSH extensions because those are relatively new, so we can assume those are conditional.

As to the legality question, it's a crappy situation. AES/SSH are not new, intel didn't even invent them, the incorporation of AES/SSH instructions behind some opcodes is absolutely trivial to anyone familiar in the art of crypto and assembly language, and yet despite these facts we genuinely don't know whether intel could successfully sue someone for emulating them.

Reply Score: 2

RE[5]: Just so we are clear...
by galvanash on Wed 14th Jun 2017 22:54 UTC in reply to "RE[4]: Just so we are clear..."
galvanash Member since:
2006-01-25

galvanash,

"I have no idea if this is the case or not,


So my word's not good enough, haha, well it's easy enough to verify independently.
"

Sorry, I meant that "I" had no idea or not as to whether the binary was compile with alternate code paths or not. I wasn't questioning your findings ;)

Reply Score: 2

RE[6]: Just so we are clear...
by Alfman on Thu 15th Jun 2017 00:57 UTC in reply to "RE[5]: Just so we are clear..."
Alfman Member since:
2011-01-28

galvanash,

Sorry, I meant that "I" had no idea or not as to whether the binary was compile with alternate code paths or not. I wasn't questioning your findings ;)


Not a problem, it's something we could chuckle over in person, but didn't come across online ;)


Speaking of which, is anyone in the NY/long island region?

Reply Score: 2

Intel doesn't own them all...
by Megol on Wed 14th Jun 2017 19:09 UTC
Megol
Member since:
2011-04-11

AMD have a number of patents related to AMD64 and other x86 things.

Reply Score: 2

o0
by sarreq on Thu 15th Jun 2017 11:55 UTC
sarreq
Member since:
2010-03-14

shouldn't the older Patents be expired by now? or has Intel pulled a Disney, and were able to get the parts of the law covering the patent expiration extended.

Reply Score: 1

From Alfman<>Brendan ideas exchange...
by dionicio on Thu 15th Jun 2017 15:09 UTC
dionicio
Member since:
2006-07-12

My next speculation is that Qualcomm could have (discretely) micro-coded whatever no longer enforceable, and on slooow emulation whatever still is.

Not believing Provider choice, on simple philia.

Being performance hit 3X% at general office applications, on sliding from 64b to 32b, worth the bite. The legacy they're fighting to carry on, is at that slice.

Some other place I read on Qualcomm being a little overconfident over this [such a little Actor, come on]. So, the bravado should be on this avenue.

Edited 2017-06-15 15:22 UTC

Reply Score: 2

Alfman Member since:
2011-01-28

dionicio,

"From Alfman<>Brendan ideas exchange..."

Your title made me chuckle, it makes it sound like Brendan's my nemesis, haha.



My next speculation is that Qualcomm could have (discretely) micro-coded whatever no longer enforceable, and on slooow emulation whatever still is.

Not believing Provider choice, on simple philia.

Being performance hit 3X% at general office applications, on sliding from 64b to 32b, worth the bite. The legacy they're fighting to carry on, is at that slice.

Some other place I read on Qualcomm being a little overconfident over this [such a little Actor, come on]. So, the bravado should be on this avenue.



Is this what it's like being on LSD? ;)

Reply Score: 2

Megol Member since:
2011-04-11

dionicio,

"From AlfmanBrendan ideas exchange..."

Your title made me chuckle, it makes it sound like Brendan's my nemesis, haha.



"My next speculation is that Qualcomm could have (discretely) micro-coded whatever no longer enforceable, and on slooow emulation whatever still is.

Not believing Provider choice, on simple philia.

Being performance hit 3X% at general office applications, on sliding from 64b to 32b, worth the bite. The legacy they're fighting to carry on, is at that slice.

Some other place I read on Qualcomm being a little overconfident over this [such a little Actor, come on]. So, the bravado should be on this avenue.



Is this what it's like being on LSD? ;)
"

That's what it's like being on machine translation. Not that hard to understand IMHO.

Answer to that post:
--
Yes Qualcomm is a small part compared to Intel but much smaller companies have successfully designed x86 processors - one in particular executed x86 via microcode on a RISC processor. IIRC not really a translation based design and with a real RISC core with very few changes rather than the "RISC" cores some say Intel and AMD have inside (they are CISC). Sadly don't remember the name of that company.

Partial emulation of those x86 parts still patented should be okay - most patents are about how to efficiently execute instructions in hardware and not emulating them with more or less significant performance impact. How easy it would be to combine that emulation with hardware support for non-patentable core features is harder to answer. The various instruction encoding extensions (REX, VEX etc.) are probably patented which would require trapping at instruction decode and doing the parsing in software (to avoid using hardware) which could be very expensive time wise.

Reply Score: 2