Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Bootcamp on M1 possible yet?
- Thread starter tbluhp
- Start date
- Sort by reaction score
You can install the ARM Insider build on the Parallels Desktop Tech Preview, both are free now, and it actually work surprisingly well.
As to navite bootcamp, don't hold your breath. Too much effort to support Apple custom hardware, I doubt that anyone will bother. Not Microsoft and certainly not Apple.
That's impressive. x86 has a lot of instructions that can be issued with multiple argument formats, so this doesn't seem particularly easy.
As far as I know, they said that they are working on it.
Well, it's the ARM build of Windows. It does come with a x86-to-ARM transpiler to run Intel software, just like Rosetta2 does.
While x86 does have a lot of instruction formats but I wouldn't' say that it's either particularly difficult or challenging to parse them or even to translate them to ARM machine code. An x86 disassemble can be written over a weekend by any moderately competent and passionate programmer (not that they will need to given how much code for this is readily available) and machine code is just that — code, so you can treat it as any other esoteric programming language use an optimizing compiler framework such as LLVM to generate matching code in a different ISA.
Now, making that transpiled code quick and correct — that's the difficult part. There are a lot of little things one has to work around, Apple actually ended up building in custom hardware support to emulate some x86 behavior. In contrast, Microsoft simply converts the code and tells you "well, if it crashes or behaves weirdly, try starting it in paranoid mode which will cut the performance down by another 50%". Tells you all you need to know about the culture of both companies
And to make it usable they also need to provide Vulcan and OpenCL drivers (I think Windows has an OpenGL emulator just like ARM Macs...)
Well, it's the ARM build of Windows. It does come with a x86-to-ARM transpiler to run Intel software, just like Rosetta2 does.
While x86 does have a lot of instruction formats but I wouldn't' say that it's either particularly difficult or challenging to parse them or even to translate them to ARM machine code. An x86 disassemble can be written over a weekend by any moderately competent and passionate programmer (not that they will need to given how much code for this is readily available) and machine code is just that — code, so you can treat it as any other esoteric programming language use an optimizing compiler framework such as LLVM to generate matching code in a different ISA.
Now, making that transpiled code quick and correct — that's the difficult part. There are a lot of little things one has to work around, Apple actually ended up building in custom hardware support to emulate some x86 behavior. In contrast, Microsoft simply converts the code and tells you "well, if it crashes or behaves weirdly, try starting it in paranoid mode which will cut the performance down by another 50%". Tells you all you need to know about the culture of both companies
Recompiling doesn't seem that easy, particularly in the presence of system specific ABI tweaks, such as vectorcall in Windows and other various quirks. x86 tends to expose a different number of fpu register names and instruction formats with pointer or register operands for its last operand, using 3 address form. It's different enough that I imagine lots and lots of weird boilerplate going into any kind of translation.
Do you even need to worry about ABI? My understanding is that you just translate the code... as long as you match the semantics of the original machine, the ABI can be as weird as it wants to be. The only time when you have to worry about the ABI is when you call from the transpiled code into the host native code, but in this case the ABI is known and can be matched.
Well, sure, but none of these cases are really complicated, it's just a lot of different things to check. You are also probably using some sort of an intermediate representation (like LLVM IR). There will definitely be boilerplate, but I assume that much of it can be optimized away in real world. Some instructions (like SSE mask family) will need more boilerplate than others, and I can imagine that some sequences of x86 instructions can be collapsed into a single ARM one (e.g. register pair load/store, auto-increment addressing mode etc.). The worst offenders, like x87 FPU will need to be implemented as library functions, but that's also not a big deal.
I was referring to the number of things that have to be matched up there. This doesn't seem like a simple task to me, although I've never tried to write any kind of emulator. x86 has significant differences. ISAs excluding AVX512 expose 16 fpu register names. Neon for example uses 32. Since x86 has fewer, intel tends to overload instructions to allow folding loads. The need to split these instructions into a load followed by an arithmetic operation seems to make this more complicated.
x87 is probably not used too much these days. It was marked deprecated around 20 years ago. For extended precision needs, it would be better to adopt something like binary128 rather than rely on the x87 stack, where any register spill effectively alters the result of your calculations.
First, even without dedicated driver support, Windows would have to be bootable. Currently, even the ARM version, isn’t seen as a bootable device in the M1... so it’s pretty much a non starter (no pun intended lol).
Windows uses a UEFI to boot on. M1 Macs use something very different.
Windows uses a UEFI to boot on. M1 Macs use something very different.
You are absolutely right, but all these are fairly straightforward engineering problems. Not to mention that you won't be converting code directly, you'd use a suitable RISK-like IR with an optimizing layer. That layer will reduce most of the boilerplate, producing reasonable translations in many common cases.
Again, these are all solved problems. QEMU has been doing this for a while. For lifting x86 to LLVM IR, this is hat a quick google search gave me: https://github.com/lifting-bits/mcsema (I am sure there are other projects like this).
The really difficult stuff is the subtle architectural semantics, like memory ordering guarantees and cache behavior. That's not something you can emulate easily (or efficiently).
All true, but you stillahve to support it. Otherwise you'd see crashes on some legacy software. Personally I think it's idiotic that x86-64 didn't take the chance to purge the ISA, but then again they were going for something quick and mostly backwards compatible.
I remember in an article, Apple says that they are open to it, and they said that it's up to Microsoft whether M1 bootcamp will ever happen. IMO, I don't see why Microsoft would oppose to it. So, let's wait and see, but it's not going to be a short term thing.
Apple supports custom kernel boot, Corellium uses that for instance to load the native Linux kernel. I suppose something similar could be done for Windows. Of course, Windows would need to patch their kernel to deal with Apple's non-standard CPU low-latency message passing implementation, custom hardware protocols... ugh, I think I'll stick to virtualization
I don't think they talked about bootcamp, they were talking about virtualization. Bootcamp is too much work. Unless Windows sells a special "Windows ARM Mac edition" for good $$$ to fund driver development and support...
No, it's about bootcamp...
Craig Federighi: Native Windows on M1 Macs is 'Really up to Microsoft'
Following the release of the M1 Macs Apple executives have been doing interviews with a range of publications, and today, Ars Technica published...
www.macrumors.com
Edit: Actually, "natively" can take on different meanings depending on your interpretation. I guess we'll see..
Lets face it Apple was never that bothered about Bootcamp in terms of updated drivers for their own hardware.
I have a bootcamp installation on my 2012 rMBP (now retired) and in something like 7 years they updated the drivers once and their new video driver actually made the thing unusable. The only way to use the system was to constantly remember never to update the video driver. Pretty shoddy really.
I have a bootcamp installation on my 2012 rMBP (now retired) and in something like 7 years they updated the drivers once and their new video driver actually made the thing unusable. The only way to use the system was to constantly remember never to update the video driver. Pretty shoddy really.