Hacker News Reader

Comment by roblabla | Hacker News Reader

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.

View on HN

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?

> 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.

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?

Reply on news.ycombinator.com