Hacker News Reader

Comment by dboreham | Hacker News Reader

Windows (really: NT) has always been hardware independent. So it's a matter of a) having binaries and a HAL (Hardware Abstraction Layer) for aarm64 (this exists -- Microsoft already sells arm-based devices such as the Surface Pro X), and b) having the necessary set of device drivers. These may exit already from MS, or may need to be compiled from source already used for x86, or may need to be written from scratch if no driver exists already. But you definitely don't need to build Windows in order to port it to new hardware, unless it's using an unsupported CPU (and then you'll have much bigger problems than just building it).

View on HN

That's only true up to a certain point. ARM is a very weird target, because a lot of standardized stuff we take for granted in x86/PC land aren't standardized on ARM. In particular, take the Interrupt Controller: x86 has a standard for it (well, technically has two, the PIC and APIC). The "standard" in ARM-land is the GICv3 or GICv4, but many different CPU vendors have their own. Apple has the "Apple Interrupt Controller", or AIC.

The thing is, AFAIK, how to talk to the interrupt controller isn't part of the drivers, but part of the kernel. So you can't just "write a driver" for it. So if Windows doesn't support apple's interrupt controllers, I guess a lot of shenanigans will be needed.

> The thing is, AFAIK, how to talk to the interrupt controller isn't part of the drivers, but part of the kernel. So you can't just "write a driver" for it. So if Windows doesn't support apple's interrupt controllers, I guess a lot of shenanigans will be needed.

He's planning on a thin hypervisor layer to map GIC to AIC.

Actually you might be surprised. Windows NT is _older_ than many of the "standards we take for granted in x86/PC land", and for example it does support multiple types of pre-ACPI ways of bringing up multiprocessor systems and specifically multiple types of interrupt controllers. Heck, x86 Windows even supports non-PC servers from Compaq and others; ever tried to press F5 during (old) Windows NT setup ?

As the OP said, all of this is abstracted by the Windows HAL, so it's just a matter of replacing the HAL (a separate binary). The problem is that the HAL is closed source. Outside of simple binary patches, I don't think anyone has come close to writing a new one.

ReactOS has written their own HALs.

Generally speaking part of the issue with a custom HAL nowadays is that Microsoft moved the HAL from being a DLL to being a statically linked library within the kernel (likely as a performance optimization and because there's no real need for a new HAL in most instances when HAL Extensions exist)

This merger of the kernel and HAL invariably means patching the HAL is now equivalent to patching the kernel

> x86 Windows even supports non-PC servers from Compaq

Were there x86 but non-IBM compatible models or did you mean the alternate instruction sets (Alpha, PPC, RISC)?

Not GP. I'm not sure if there's a special Compaq version but there's a version (until Windows 2000, https://winworldpc.com/download/5204c39d-c3a9-5a68-11c3-a7c2...) for NEC PC-98 architecture which is x86-based but IBM PC-incompatible, so it's likely that a Compaq version exists.

The Compaq is IBM PC compatible but uses a different HAL for SMP support. You can see all of them by looking at what NT4 shipped with for example.

Ah, Uniprocessor versus Multiprocessor HALs, I remember now!

>Outside of simple binary patches, I don't think anyone has come close to writing a new one.

What about ReactOS, do they use a HAL implementation or not?

This part is why I hope x86 has a long life ahead of it. Everybody and their dog have their own standard for things in ARM-land.

One can hope that RISC-V in the future will not follow ARM's past mistakes.

The mistakes are already happening. There are RISC-V processors being shipped with unfinished extensions and weird MMUs and now Linux has to decide whether to support those or only support finished standards

for what it's worth amd64 is not going anywhere outside of Macs for at least the next decade, possibly two.

Despite the benefits ARM provides amd64 undeniably has advantages and non-trivial ones at that.

personally, I'm of the opinion it'll come to a coexistence for a time rather than one dominating the other immediately.

Are you confusing "amd64" with "Aarch64"? "amd64" has nothing to do with Macs/Apple products.

Anyway, both amd64 and Aarch64 are already being used outside of Macs/Apple products.

Apple still sells many computers that execute the amd64 insurrection set.

This is not true.

Most manufacturers take standardized IP and IP-providers provide an appropriate linux drivers. Few manufacturers are willing to develop and maintain their own GIC hardware and GIC driver, most of the time they just take the ARM standard GIC.

The fact that Apple does not provide drivers is a consequence of the Apple business model. And the fact that the ARM ISA does not stipulate a unique GIC is actually a strength. It makes the architecture more versatile and suitable for evolution (maybe Apple found out that the ARM standard GIC is not complete enough for them).

I think that's uncharitable even if I am using superlatives to describe the situation.

We have plenty of examples in the wild. Just look at the state of Pine64 and u-boot, for example. It's a mess of standards.

And what you see as a strength others don't.

Pine64 is based on an Allwinner A64 which has a ARM GIC-400. ARM GIC-400 is a standard GIC IP from ARM and compliant with ARM GICv2 specification.

It seems pretty standard to me, not a custom GIC as Apple.

And yes, in u-boot there are plenty of device-trees for each target. What's wrong with that?

The device tree is usually provided by the manufacturer, the compiled device tree is usually very small and allows genericity.

The author plans on using this feature to help bridge the interrupt controller:

“There’s an somewhat obscure feature on M1 (and M1 Pro/Max/Ultra, henceforth referred to as M1 v2) chips where part of the GICv3 can be virtualized to guest OSes to enable faster interrupt handling.”

Seemingly implementing it in a hypervisor?

You also have to have the abstractions and hooks at the right places, though. Linux had that problem: The AIC (interrupt controller) is sufficiently different from the standard ARM GIC that ARMv8 Linux had to receive more fundamental patches before AIC support could be cleanly added.

To illustrate the issue with a silly example, imagine the Windows kernel assumes that every interrupt controller speaks Spanish, but suddenly AIC comes along and speaks Portuguese. The driver is going to have a hard time communicating.

A sibling commenter, gjsman-1000, explains that the idea is apparently to instead have a very lightweight hypervisor that actually presents a GIC to Windows, instead of trying to add an AIC driver, which might also have needed further kernel changes if Windows even has the concept of interrupt controller support being abstracted away enough to support interrupt controller "drivers" in its HAL. (I am not a Windows person at all, I don't know.) Basically not only having someone in between that seamlessly translates between Portuguese and Spanish, but actually pretending to be the interrupt controller itself.

Reply on news.ycombinator.com