On Tue, Dec 16, 2025, at 8:57 PM, Thomas Munro wrote: > On Wed, Dec 17, 2025 at 10:40 AM Nathan Bossart > <[email protected]> wrote:
Hey Nathan, Thomas, thanks for your continued investment of time in this patch. More thoughts below, but I wonder if the thing to do is to commit this and then for me to follow-on with a few more targeted changes to round out this platform combo? >> Hm. I think the USE_LLVM_BACKPORT_SECTION_MEMORY_MANAGER thing might need >> work, too. We don't have any Windows buildfarm machines with LLVM enabled, >> but IIUC it should be possible. Perhaps we can add that to unicorn. > > The LLVM code has never run on Windows and will likely need > patching... I know of at least one change required and will write > about that. I think it would be amazing to support this eventually, but as I'm not a MSVC or Win11 guru this feels like a longer term patch. I'm still struggling with simpler things at the moment. The platform is not well established so some libraries are missing or out of date. There's no ARM64-native Perl either. >> > Also, while the patch >> > is targeting Windows 11 (IIUC), there are some notes in the docs that give >> > the impression Windows 10 is supported, too [0]. I could easily change it >> > to say that AArch64 requires Windows 11, but I don't know what to do with >> > the references to specific versions of Visual Studio and the Windows SDK. When I get a chance I'll post a docs patch for debate/review. >> Actually, I'm not sure there's anything specific to Windows 11 in this >> patch, besides perhaps the choice to set USE_ARMV8_CRC32C unconditionally. >> I don't know how likely it is that someone will try to run Postgres on >> Windows on an AArch64 machine without CRC extension support, though. > > Assuming you haven't blocked OS updates, Windows stopped booting on > pre-ARMv8.1 hardware a while back. RPi4's Broadcom chip and the > Snapdragon 835 (found in the oldest Windows laptops, according to a > quick Google search) are ARMv8-A only, but did actually have the CRC32 > instructions, so it would actually work anyway. They also have the > optional NEON SIMD stuff, which we use unconditionally: > > /* > * We use the Neon instructions if the compiler provides access to them (as > * indicated by __ARM_NEON) and we are on aarch64. While Neon support is > * technically optional for aarch64, it appears that all available 64-bit > * hardware does have it. Neon exists in some 32-bit hardware too, but we > * could not realistically use it there without a run-time check, which seems > * not worth the trouble for now. > */ > > A single chip in this report lacked FEAT_CRC32, the X-Gene 1 from 2012: > > https://gpages.juszkiewicz.com.pl/arm-socs-table/arm-socs.html > > So I don't think it's worth worrying about, I was just mentioning the > "Windows 11 requires CRC32, Windows 10 is dead" thing to avoid Greg > being forced to waste time researching the missing feature test code > :-) The reason Windows can't boot on old ARM chips probably has more > to do with the modern atomics needed for decent lock performance, > which every kernel wants. I think there are a few things to offer up in the next few weeks: * docs * popcnt * SIMD * wiki page with HOWTO info for the next "brave" soul to give this a go * what else? What this patch does is get "unicorn" off the dead list, which would be nice. -greg
