Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Microsoft

Microsoft and Qualcomm Team Up To Create a Windows on ARM Developer PC (theverge.com) 60

Posted by msmash from the shape-of-things-to-come dept.
Microsoft has teamed up with Qualcomm to create a Windows on ARM-based dev kit for developers. From a report: The miniature PC will be sold at the Microsoft Store this summer, and is designed to be more affordable to encourage developers to create ARM64 apps for Snapdragon-based PCs. Until now, developers have had to purchase devices like the Surface Pro X to fully test their ARM64 apps on Windows. That's a costly exercise for developers, particularly when the Surface Pro X retails from $999 and up. While Microsoft and Qualcomm haven't put a price on this new dev kit, there are promises it will be more affordable than what developers can buy today. "This developer kit provides an affordable alternative to other consumer and commercial devices," says Miguel Nunes, senior director of product management at Qualcomm. "With the smaller desktop configuration, this kit gives developers more flexibility than notebook options, and at a lower price point."
This discussion has been archived. No new comments can be posted.

Microsoft and Qualcomm Team Up To Create a Windows on ARM Developer PC More

Microsoft and Qualcomm Team Up To Create a Windows on ARM Developer PC

Comments Filter:
  • That work with socketed processors, and accepts PCI express graphics cards. Back in the 90s Socket 7 motherboards were a semi open standard, and could accept cpus from Intel, AMD, Cyrix and IDT. Something like this with ARM would be great.

  • The miniature PC will be sold at the Microsoft Store this summer, and is designed to be more affordable to encourage developers to create ARM64 apps for Snapdragon-based PCs.

    Glad the ARM drivers problem has been solved.

  • Does it run Linux (or BSDs) directly (not under Windows) ? If not, sorry. Hardware seems nice though.

    • More importantly, how long has it run NetBSD? Presumably longer than it's been capable of running Windows, since many developers port NetBSD first to shake out the hardware.

    • Given the windows surface ARM version (along with significant issues with the x86 version) is completely locked to windows I would bet they've locked the boot so it will only load a signed windows boot like they've done with their other products.

      https://github.com/Sonicadvanc... [github.com]

      This usually ties to the fact that Qualacomm will not create or allow the creation of drivers for other OS's and their tendency to spin custom SOC's for each PC type device. You'll note in my link that less than half the hardware wor

    • Does it run Linux?â

      Probably not; but an M1 equipped Mac does:

      https://news.itsfoss.com/linux... [itsfoss.com]

  • About what you will get with this mini-PC.
  • Parallels on the M1 runs Windows 10 ARM64 in a virtual machine with better performance that Surface Pro X. Right now. Today.
    • It was interesting when testers found this out. The first instance of MacOS on ARM will run Windows x86 applications via VM better than Windows on a Surface Pro natively. It says the x86 translation circuitry Apple built in to the M1 CPUs has a significant performance improvement.
      • It's not just translation circuity, Apple has developed their own implementation of ARMv8 that performs better across the board than the stock IP that Qualcomm licenses from ARM Holdings.
        • That too but here is where Apple has an advantage over Qualcomm. Qualcomm has no experience and probably did not care about x86 APIs as they only deal with ARM. Apple needed to care about both as they used Intel and ARM chips. Maybe with MS, Qualcomm can put more work into it but again Apple has been working with Intel closely on hardware for many years now while MS has only a small amount of experience.
      • What "x86 translation circuitry"? I have not heard of such thing regarding M1, unless you mean the strong memory model support, even if that is not actually "x86 translation" in the first place.
        • Emulation acceleration hardware is a better way to put it. For instance, Apple has implemented a scheme that lets dynamic code translators (Rosetta 2, for example) transition between code translation and execution without have to perform a kernel call.
          • Why would you *need* a kernel call for that? I mean, outside of Apple's bizarre ecosystem where executing your own generated code is a no-no for everyone except Apple.
            • On transition from code translation to execution, it is necessary to (1) flush the i-cache so that stale ops are evicted and (2) change the dynamic code cache from rwx to rx. Both operations normally require execution level 2 or above, meaning a task switch into the kernel is required; however, with Apple's enhancements, execution level 3 has tightly controlled access to these operations without calling the kernel. Not sure what you mean by a "no-no" as Apple exposes the interfaces to anyone that cares to u
        • Then you have not been paying attention. These are the facts: a M1 Mac via VM runs Windows x86 applications faster than Windows running the same x86 apps on Qualcomm's ARM chips. Either Apple has figured out how to make their software only translation much better/faster than MS can with Windows (and doing through a VM) or there is hardware assistance. Considering that Apple has lots of experience with x86 while Qualcomm does not, the logical conclusion is that there is some hardware assistance.
          • I have been paying attention, and what you're describing does not imply any "x86 translation circuitry".

            a M1 Mac via VM runs Windows x86 applications faster than Windows running the same x86 apps on Qualcomm's ARM chips

            Because Qualcomm's ARM chips are *way* slower [cpu-monkey.com], duh. Even equal translation will give you this result.

            the logical conclusion is that there is some hardware assistance.

            No, it isn't, unless you're talking about the x86-compatible memory model. But that's not "translation circuitry", that's simply the designed-in behavior of the memory circuitry.

            • I have been paying attention, and what you're describing does not imply any "x86 translation circuitry

              Specialized hardware circuitry that helps the M1 with x86 instructions that no other ARM chip has is what to you? I can assure you such circuitry is not part of the ARM ISA.

              Because Qualcomm's ARM chips are *way* slower [cpu-monkey.com], duh. Even equal translation will give you this result.

              And the fact that the M1 could run x86-64 apps via VM before Windows on ARM could do that is all because the M1 is "faster". Again, you are not paying attention. Windows on ARM still does not run 64 bit apps very well or sometimes at all.

              No, it isn't, unless you're talking about the x86-compatible memory model. But that's not "translation circuitry", that's simply the designed-in behavior of the memory circuitry.

              Again, Windows on ARM cannot run x86-64 apps very well or at all sometimes AND did not offer that as

              • Specialized hardware circuitry that helps the M1 with x86 instructions that no other ARM chip has is what to you?

                Provide examples for your claims. What specialized circuitry and what x86 instructions?

                Again, you are not paying attention. Windows on ARM still does not run 64 bit apps very well or sometimes at all.

                Again, Windows on ARM cannot run x86-64 apps very well or at all sometimes AND did not offer that as an option until after M1 Macs were released.

                Except nobody disputed the shittiness of Microsoft's software here. That hasn't been exactly a secret, including the limitations of Microsoft's ARM software.

                Sure it all had to do with the M1 being faster. It had nothing to do with the fact that Apple used both software and hardware to run x86.

                Of course Apple used hardware. They aren't doing the calculations with pencil on paper.

                • Have you thought for one second how Apple was/is able to run x86-64 apps via Windows VM and MS cannot? And do it before MS? If you had thought about it for one second, your answer : "Well, Apple has faster chips" makes no sense. Apparently your first reaction is to defend your lack of thought.
                  • Well, yes -- because Apple moved to 64 bits on ARM fairly quickly -- it shipped in 2013, eight years ago, and thus they've been dealing with generating ARM64 code for a long time, hence much more experience on their part. Compared to that, Microsoft, which stayed on 32-bit ARMs for a very long time since it treated ARM as a second-class architecture for really cheap devices -- it moved to ARM64 in 2018, only three years ago, and didn't bother with emulating 64 bit code on 32 bit devices which would have bee
                    • You do know the Qualcomm chips that MS is CURRENTLY using is 64 bit? Or have you not been paying attention? Let me guess: that one fact "destroys" all of your points. Do these facts escape you?
                    • Yes, that's why they can finally do such a thing as AMD64 emulation in the first place. As long as they didn't bother with higher-end ARM chips, they couldn't -- or at least meaningfully. (Of course you can emulate any machine on any Turing-complete machine but that is not a claim to practicality.)

                  • your answer : "Well, Apple has faster chips" makes no sense

                    BTW, that ^^^ is an awful straw man on your part: my "Apple has faster chips" was not a response to "how Apple was/is able to run x86-64 apps via Windows VM and MS cannot", but a response to "M1 Mac via VM runs Windows x86 applications faster than Windows running the same x86 apps on Qualcomm's ARM chips" [slashdot.org]. Please stop being so blatantly disingenuous. Higher performance of M1 vs. Qualcomm is because of the much faster M1 chips compared to Qualcomm's chips. Apple having AMD64 Windows app support before MS is

                    • Your entire premise: "Since I have never heard of it, it cannot be true." Me: "Here’s proof.” You: "Yes that is true but it does not count."

                      Which is it? Did you know and forgot or are you a denier?

                    • You didn't provide any proof of x86 instruction translation circuitry in M1.
                    • Bahahaha. The same evidence you said was not evidence. Basically since it does not say what you want it to say you are going to deny it then. The Nile is not just a river in Egypt.
                    • I was asking for circuitry translating x86 ISA to ARM ISA, for example a separate hardware decoder front-end in parallel to the ARM one, or Transmeta-like circuitry. We've successfully established here that as far as the public knows, there's no such circuitry in M1, and that Apple is transpiling the binary code in software.

          • These are the facts: a M1 Mac via VM runs Windows x86 applications faster than Windows running the same x86 apps on Qualcomm's ARM chips. Either Apple has figured out how to make their software only translation much better/faster than MS can with Windows (and doing through a VM) or there is hardware assistance.

            If by "hardware assistance" you mean "a CPU that is simply faster at everything", then sure. I admittedly may have missed it, but I'm not aware of any indication Apple has built special circuitry into the M1 to aid in translation, though the fact that the M1 is faster than the chip in the Surface Pro at everything is an obvious explanation for why it's doing better at running those same x86 apps, but in a VM.

            You can still beat the competition without purpose-built circuitry if you're faster in the general u

            • According to some people, Apple added Intel's x86 memory model in their CPUs [twitter.com]This is what people have discovered so far.

              • With underlying architectural issues ironed out, running x86 code simply means translating those instructions to the Arm equivalent.

                The author of those tweets single-handledly destroyed your claim about special hardware support for x86 instructions, arguing that what actually happens is that Apple is simply running regular ARM instructions with stricter memory behavior.

                Also, he's saying exactly the same things that I'm saying elsewhere in this thread. So thank you for supporting my own arguments.

                • The author of those tweets single-handledly destroyed your claim about special hardware support for x86 instructions, arguing that what actually happens is that Apple is simply running regular ARM instructions with stricter memory behavior.

                  What the hell are you taking about? The author clearly says that Apple baked into the CPU silicon x86 memory handling. To you that is not support of x86 and that this not hardware even though it is both. I do not know if you know that this handling does absolutely nothing for ARM CPUs. This circuitry is not found on another other ARM CPUs even from Apple much less the multiple ones MS has used for their Windows on ARM machines over the last 8 years. My take from this is that when presented proof of somethin

                  • What the hell are you taking about? The author clearly says that Apple baked into the CPU silicon x86 memory handling.

                    I already said [slashdot.org] that this is the only feature of the M1 chips that I can think of that could possibly qualify as "x86 support", and it has nothing to do with instruction translation. So I said exactly the same thing that this tweet author said, you've just completely missed it, apparently. This is no "translation circuitry" of any sort -- it doesn't translate anything. All the instructions are translated by a software component.

                    To you that is not support of x86 and that this not hardware even though it is both.

                    It *is* hardware support but it is *not* "translation circuitry" of any sort. Als

  • The raspberry pi 400 is 99$.
    So if they want to be affordable, that's the price to match.

    • These two things serve completely different purposes. What Microsoft and Qualcomm are offering is more akin to a Mac mini than anything.

      • If I am going to spend coin it will be on a M1 Mac. If I decide to ditch it later I can assume I might get 90% to 50% back. A windows machine used is a 90% loss. Everyone I know will take a Mac, everyone I know has had enough MS Windows and what they have is good enough...

  • Because porting Windows to the RPi was nixed by Capt. Obvious.

    • Re: (Score:2)

      by caseih ( 160668 )

      Except a stripped down version of Windows 10 already runs on the pi and has for some time. Not that it's at all useful.

      • Except a stripped down version of Windows 10 already runs on the pi and has for some time. Not that it's at all useful.

        "Not being useful" is a "feature" of Windows, so is necessary for compatibility.

  • Windows RT, WOA, WOA2... All the problems of Apple on ARM with none of the charms...
    • Also the solution of a mostly software company like MS is to rely on software. Apple being a hardware and software company uses both. I guess it comes down to the saying, when all you all have is a hammer, everything looks like a nail.

  • Is Qualcomm going to support it for 10 years? (Score:3)

    by Wokan ( 14062 ) on Tuesday May 25, 2021 @07:03PM (#61421836) Journal

    If Qualcomm follows their usual plan, these things will be junk in 2-3 years with no resale value and no upgrade path.

Slashdot Top Deals

I've noticed several design suggestions in your code.

Close