# x86-64 Published articles for x86-64. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Announcing rustup 1.29.3 DevFeed: [Announcing rustup 1.29.3]() Original publisher: [Read original article]() Author: The Rustup Team Published: 2026-11-03T00:00:00Z Content type: release Language: en Sources: [Rust]() Topics: [project release](), [releases](), [Rust](), [malware scanners]() Tags: [automatically](), [cpus](), [download](), [error](), [fixed](), [how-to](), [illegal](), [init](), [lock](), [malware](), [malware-scanners](), [patch](), [point](), [rust](), [rustup](), [scanners](), [solaris](), [toolchain](), [update](), [x86-64]() ### AI overview Rustup 1.29.3 fixes an "Illegal instruction" error on some x86_64 CPUs without SSE4.1 and a "lock() not supported" error on Solaris. To update, stop programs that may be using rustup and run `rustup self update`; `rustup update` also updates rustup after a toolchain update. If self-update fails, the source describes manually replacing the rustup binary with the platform's `rustup-init`, after ensuring no other rustup processes are running. Anti-malware scanners may temporarily block file operations, especially when installing rust-docs. ### Source excerpt The rustup team has published a new point release of rustup, 1.29.3. Rustup is the recommended tool to install Rust, a programming language that empowers everyone to build reliable and efficient software. What's new in rustup 1.29.3 This new patch release has fixed some minor regressions over the previous one: Fixed "Illegal instruction" error on certain x86_64 CPUs without SSE4.1. pr#5162 Fixed "lock() not supported" error on Solaris. pr#5167 Further details are available in the changelog! How to update If you have a previous version of rustup installed, getting the new one is as easy as stopping any programs which may be using rustup (e.g. closing your IDE) and running: $ rustup self update Rustup will also automatically update itself at the end of a normal toolchain update: $ rustup update For this particular release, if you have encountered any issues during self-update, you may try to update rustup manually by following the steps below: Download the corresponding rustup-init binary for your platform. Make double sure that no other rustup processes are running. Replace your existing rustup binary with the downloaded rustup-init renamed to rustup. As a reminder, this binary is often located at $HOME/.cargo/bin/rustup, or $CARGO_HOME/bin/rustup if you have overridden the $CARGO_HOME environment variable. If you don't have it already, you can get rustup from the appropriate page on our website. Rustup's documentation is also available in the rustup book. Caveats Rustup releases can come with problems not caused by rustup itself but just due to having a new release. In particular, anti-malware scanners might block rustup or stop it from creating or copying files, especially when installing rust-docs which contains many small files. Issues like this should be automatically resolved in a few weeks when the anti-malware scanners are updated to be aware of the new rustup release. Thanks Thanks again to all the contributors who made this rustup release possible! ## The Flash C compiler DevFeed: [The Flash C compiler]() Original publisher: [Read original article]() Author: Anne Barela Published: 2026-10-31T14:00:58Z Content type: release Language: en Sources: [Adafruit Industries]() Topics: [Compiler](), [toolchain](), [linker](), [Linux]() Tags: [c](), [compiler](), [debugger](), [elf](), [flash](), [floating-point](), [functions](), [github](), [help](), [ide](), [layout](), [library](), [linker](), [linking](), [linux](), [screen](), [software](), [source](), [static](), [text](), [turbo](), [turbo-c-plus-plus](), [vintage-computing](), [x86-64]() ### AI overview Flash C is an x86-64 Linux C compiler and full-screen IDE written from scratch. Its fcc compiler accepts C89 with some C99 conveniences, excludes C++, and emits static ELF executables directly without an assembler, linker, or host C library. Its runtime library is embedded in the compiler; only functions reachable from main are emitted, including floating-point conversion routines only when float or double is used. The optimizer has 48 passes that can be toggled individually. The fc IDE uses a Turbo Vision-style interface and includes a ptrace/int3 source debugger and hyperlinked help. The author says Turbo C++ 3.1 was studied to reproduce interface details, but its code and resources were not used. ### Source excerpt Dilshan Jayakody has released Flash C, a C compiler and full-screen text-mode IDE written from scratch for x86-64 Linux, documented on his Web Log. The compiler, fcc, reads C source and writes a static ELF executable directly. No assembler, linker or host C library is involved. Flash C handles C89 plus a few C99 conveniences [...] ## BUSTA: Teaching Small Language Models to Reason About Binary Execution DevFeed: [BUSTA: Teaching Small Language Models to Reason About Binary Execution]() Original publisher: [Read original article]() Author: Ritika Poddar, Aidan Fennelly, Deirdre Murphy, Eric Wolos, Corre L. Steele, Michael Doyle Published: 2026-10-28T04:00:00Z Content type: article Language: en Sources: [arXiv: Artificial Intelligence](), [arXiv: Cryptography and Security](), [arXiv: Machine Learning]() Topics: [llm-reasoning](), [grpo](), [code analysis](), [Large Language Model](), [qwen](), [Nemotron]() Tags: [cs-ai](), [cs-cr](), [cs-lg](), [cs-pl](), [execution](), [fine-tuning](), [grpo](), [language-models](), [nemotron](), [qwen3](), [reverse-engineering](), [training-dataset](), [x86-64]() ### AI overview BUSTA fine-tunes small open models to reverse x86-64 basic-block execution: given a block and desired output register state, they predict input register values. Using Group Relative Policy Optimization, Qwen3-1.7B's knowable-register accuracy rises from 73.2% to 85.3%, while Nemotron-3-Nano's rises from 63.3% to 95.2%. Frontier models still lead, reaching 99.2%, but fine-tuned Nemotron-3-Nano comes within four points with far fewer parameters. The authors say they release both fine-tuned models and the training dataset. ### Source excerpt arXiv:2610.36288v1 Announce Type: cross Abstract: Large Language Models (LLM) are increasingly applied to Reverse Engineering (RE) workflows. RE, however, differs from common LLM coding tasks as it requires models to reason about low-level program behavior. Furthermore, the deployment of tooling in resource-constrained sandboxed RE environments limits the ability to use frontier-scale solutions. We examine whether a targeted LLM training approach can transfer distinct RE skills to open models via inverse basic-block execution: given an x86-64 basic block and a desired output register state, the model predicts the input register values that produce it. Fine-tuning \texttt{Qwen3-1.7B} and \texttt{Nemotron-3-Nano} with Group Relative Policy Optimization (GRPO) raises knowable-register prediction accuracy from 73.2\% to 85.3\% and from 63.3\% to 95.2\%, respectively. Frontier models still score highest (up to 99.2\%), but our fine-tuned \texttt{Nemotron-3-Nano} comes within four points at a fraction of the parameter count. We release both fine-tuned models and the training dataset. ## Linux 7.4 Kernel Crypto Library Enjoying Optimized AES Implementations On x86 & RISC-V DevFeed: [Linux 7.4 Kernel Crypto Library Enjoying Optimized AES Implementations On x86 & RISC-V]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-10-21T20:11:03Z Content type: news Language: en Sources: [Phoronix]() Topics: [Linux Kernel](), [Linux](), [x86](), [Library](), [RISC-V]() Tags: [2026](), [7-4](), [accelerated](), [acceleration](), [aes](), [crypto](), [cryptographic](), [desktop-linux](), [engineer](), [faster](), [google](), [kernel](), [library](), [linux](), [linux-7-4](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-kernel](), [linux-performance](), [linux-server-benchmarks](), [open-source-graphics](), [optimized](), [performance](), [phoronix](), [phoronix-test-suite](), [risc-v](), [ubuntu-benchmarks](), [ubuntu-hardware](), [x86](), [x86-64]() ### AI overview Merged for Linux 7.4, optimized AES implementations for ECB, CBC, CBC-CTS, CTR, XCTR and XTS were moved into the kernel crypto library for x86/x86_64 and RISC-V. This accelerates the library APIs on those architectures while preserving acceleration for crypto_skcipher; x86_64 uses AVX-optimized code and AES-NI. The change also removes duplicated glue code. Separately, SPARC64 gains an optimized AES-XTS implementation using its crypto opcodes. ### Source excerpt The latest Linux kernel cryptographic subsystem performance work carried out by Google engineer Eric Biggers is migrating x86/x86_64 and RISC-V optimized implementations of different AES modes into the lib/crypto kernel crypto library to enjoy faster performance there... ## CAFS: A Cache-Aware Frequency Sort for Low-Cardinality Integer Data on x86-64 DevFeed: [CAFS: A Cache-Aware Frequency Sort for Low-Cardinality Integer Data on x86-64]() Original publisher: [Read original article]() Author: Vasiliy S. Shlyk Published: 2026-10-21T04:00:00Z Content type: article Language: en Sources: [arXiv: Databases]() Topics: [vectorization techniques](), [Cache](), [CPU Cache](), [x86](), [olap]() Tags: [adaptive](), [algorithm](), [array](), [avx2](), [cache](), [cardinality](), [cs-db](), [cs-ds](), [olap](), [open-addressing](), [operational](), [pdqsort](), [radix-sort](), [simd](), [ska-sort](), [sort](), [throughput](), [x86-64]() ### AI overview CAFS targets integer arrays with many values but low cardinality, common in OLAP workloads. On x86-64 with AVX2, it combines a cache-line-sized SIMD bucket, a Chao1 estimator using 1,024 strided samples, and an adaptive dispatcher with a spill safety guard; its branchless hot loop uses cmpeq, movemask, and tzcnt. Across 592,770 benchmark runs, CAFS reached 1.7-3.1x pdqsort, 1.7-3.5x IPS4o, and 1.2-2.3x vqsort throughput when K was much smaller than N. The reported crossover is about K=130,000 for pdqsort and 670,000 for vqsort; only vqsort overtook CAFS beyond its crossover, making that threshold the stated limit of CAFS's operational range. The evidence is an abstract-level summary of benchmarks, not full paper coverage. ### Source excerpt arXiv:2605.25040v2 Announce Type: replace-cross Abstract: Integer sorts in OLAP engines often run on columns whose cardinality $K$ is much smaller than the array length $N$. After a group-by stage the intermediate key column has $K$ bounded by the number of distinct group keys, and even a column-store scan typically operates on dictionary-encoded categorical fields where $K$ never exceeds a few thousand. A comparison sort on such a column still pays $\Theta(N \log N)$ comparisons, and a radix sort still pays $\Theta(N \cdot B/b)$ byte passes, irrespective of $K$. This paper describes CAFS, an integer sort that does exploit it on x86-64 with AVX2. The algorithm combines a SIMD bucket sized to one cache line, a Chao1 cardinality estimator over 1024 strided samples (kept in a heap-allocated 40 KB open-addressing table), and an adaptive dispatcher backed by a spill safety guard. The hot loop is branchless and uses AVX2 cmpeq together with movemask and tzcnt to locate the matching lane. We benchmarked CAFS on a full-factorial grid of 58 array sizes $N$ from $10^3$ to $3 \cdot 10^7$ with dense $K$ schedules per $N$, producing 592770 timed runs against pdqsort, IPS4o, vqsort, ska_sort, and std::sort. In the $K \ll N$ band the throughput is 1.7 to 3.1x that of pdqsort, 1.7 to 3.5x IPS4o, and 1.2 to 2.3x vqsort. The operational crossover against pdqsort is at $K \approx 1.3 \cdot 10^5$; against ska_sort, $K \approx 8.14 \cdot 10^5$; against vqsort, $K \approx 6.7 \cdot 10^5$; and against IPS4o the curves only converge near $K = N$. Of the five baselines, only vqsort actually overtakes CAFS once the crossover is passed, which makes the vqsort threshold at $K \approx 6.7 \cdot 10^5$ the binding constraint on the operational range of CAFS. ## CodeQL changes for macOS 27, Xcode 27, and Swift 6.4 DevFeed: [CodeQL changes for macOS 27, Xcode 27, and Swift 6.4]() Original publisher: [Read original article]() Author: Allison Published: 2026-10-19T10:29:09Z Content type: release Language: en Sources: [GitHub Changelog]() Topics: [Xcode](), [macOS](), [Swift](), [CI/CD]() Tags: [2026](), [actions](), [apple](), [application-security](), [binaries](), [builds](), [code](), [codeql](), [github](), [intel](), [libraries](), [macos](), [macos-27](), [retired](), [swift](), [swift-6-4](), [system](), [trace](), [with](), [x86-64](), [xcode](), [xcode-27]() ### AI overview Starting with macOS 27 and Xcode 27, Apple's removal of Intel code from some system binaries and libraries prevents CodeQL from supporting traced scans on those versions; CodeQL also does not support Swift 6.4 on any platform. With Xcode 27 installed, traced extraction is unavailable for C/C++, C#, Go, Java, Kotlin, and Swift; on macOS 27 it may be unavailable for those languages. Intel Mac support is slated for deprecation in mid-December 2026. The excerpt advises pinning workflows to macOS 26 or earlier and Xcode 26 or earlier, including GitHub Actions runner images and toolchains. For C/C++, C#, and Java, build mode `none` is an option that does not require build tracing. ### Source excerpt Starting with macOS 27 and Xcode 27, Apple no longer includes Intel (x86_64) code in some of the system binaries and libraries that CodeQL relies on to trace builds. As... The post CodeQL changes for macOS 27, Xcode 27, and Swift 6.4 appeared first on The GitHub Blog. ## Asterinas 0.19.0 Brings Up X.Org & Other Improvements To This Rust-Written OS DevFeed: [Asterinas 0.19.0 Brings Up X.Org & Other Improvements To This Rust-Written OS]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-10-13T10:14:11Z Content type: news Language: en Sources: [Phoronix]() Topics: [ReactOS](), [Rust](), [Linux](), [no\_std]() Tags: [ai-code-review](), [code](), [desktop-linux](), [drm](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [open-source](), [open-source-graphics](), [os](), [phoronix](), [phoronix-test-suite](), [risc-v](), [rust](), [ubuntu-benchmarks](), [ubuntu-hardware](), [x86-64]() ### AI overview Asterinas 0.19 adds an initial DRM subsystem and runs X.Org with a modesetting driver and Mesa's LLVMpipe OpenGL driver. The Rust-based OS also adds initial AArch64 support and continues work on secure containers, a Rust-native driver device model, self-hosting, and AI code review. ### Source excerpt Asterinas is the open-source project developing a Rust-based, memory-safe Linux alternative OS while striving for Linux software compatibility. Out now is Asterinas 0.19 as the project continues advancing on its goals... ## Graft: replace dependencies CLI DevFeed: [Graft: replace dependencies CLI]() Original publisher: [Read original article]() Author: tomberek Published: 2026-10-13T02:16:04Z Content type: article Language: en Sources: [Announcements - NixOS Discourse]() Topics: [NixOS](), [cURL]() Tags: [announcements](), [cli](), [linux](), [nix](), [nixos](), [nixpkgs](), [openssl](), [x86](), [x86-64]() ### AI overview Graft is a command-line tool for replacing dependencies in Nix store paths without reevaluating Nix expressions. The discussion demonstrates swapping curl's OpenSSL dependency and editing generated NixOS configuration, while warning that grafting libraries can cause compatibility failures. ### Source excerpt (claude was used... extensively) Graft replaces dependencies at the store layer, bypassing the normal Nix eval. Inspired by Guix graft. While we do have replaceDependency and system.replaceDependencies I thought it would be nice to have a Guix-style CLI to run grafts more manually and without having to re-evaluate Nix expressions that you may/may-not still have around. Eg: $ nix run nixpkgs/nixos-25.11#curl -- --version curl 8.20.0 (x86_64-pc-linux-gnu) libcurl/8.20.0 OpenSSL/3.6.2 ... $ export curl="$(nix eval nixpkgs/nixos-25.11#curl.outPath --raw)" $ graft replace $curl --override-name openssl nixpkgs/nixos-26.05#openssl.out ... grafted /nix/store/r4p5r6q0n3lmidd0yq2zblqxvim0xsb3-krb5-1.22.1-lib -> /nix/store/nxa80mkh75x6cik14mqcbd0d34b3c1nz-krb5-1.22.1-lib grafted /nix/store/rngyrpv421p1cnn78d5ph2y5ylg133n7-curl-8.20.0 -> /nix/store/qap31yikgr3hadwg455pl96k8rs2bbjn-curl-8.20.0 grafted /nix/store/2nmfyy3jjgn2m8d1p7lwbbxakl4ciwfc-curl-8.20.0-bin -> /nix/store/yklqiif3wxlh67sidmaflv7il2dykmn6-curl-8.20.0-bin 5 grafted, 1 explicit replacement, 15 unchanged (21 total) /nix/store/yklqiif3wxlh67sidmaflv7il2dykmn6-curl-8.20.0-bin $ /nix/store/yklqiif3wxlh67sidmaflv7il2dykmn6-curl-8.20.0-bin/bin/curl --version curl 8.20.0 (x86_64-pc-linux-gnu) libcurl/8.20.0 OpenSSL/3.6.5 ... $ nix path-info -r /nix/store/yklqiif3wxlh67sidmaflv7il2dykmn6-curl-8.20.0-bin | grep openssl /nix/store/kysvfcf8d8v26rr32xfqji8ri2lczlqk-openssl-3.6.5 Can this be very unsafe? YES! The tool is sharp. Beware the "Segmentation fault" and "version `GLIBC_2.43' not found" when messing with libraries. Probably safer to be replacing full executable binaries. Is this actually useful? Not sure, but there are some cases this can be useful. Let's say I want to quickly test out an edit to a config file that I just can't de-tangle from a convoluted NixOS module or I don't have the Nix expressions for: $ export EDITOR=vim $ head /etc/nix/nix.conf # WARNING: this file is generated from the nix.* options in # your ## Python 3.15 Released With Experimental JIT Compiler Running Faster DevFeed: [Python 3.15 Released With Experimental JIT Compiler Running Faster]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-10-09T14:58:00Z Content type: news Language: en Sources: [Phoronix]() Topics: [Python](), [Numba]() Tags: [c](), [compiler](), [configuration](), [desktop-linux](), [faster](), [interpreter](), [jit](), [library](), [linux](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [macos](), [open-source-graphics](), [phoronix](), [phoronix-test-suite](), [programming](), [programming-language](), [python-3-15](), [python-programming](), [release](), [standard-library](), [ubuntu-benchmarks](), [ubuntu-hardware](), [x86](), [x86-64]() ### AI overview Python 3.15 is described as introducing an experimental JIT compiler that is faster than the standard interpreter in cited benchmarks. The release also adds language and standard library changes, C API improvements, and default frame pointers for observability. ### Source excerpt Python 3.15 is out today as the newest annual feature release for the Python programming language... ## Patches Updated To Begin Removing The Linux x32 ABI DevFeed: [Patches Updated To Begin Removing The Linux x32 ABI]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-10-08T12:09:53Z Content type: news Language: en Sources: [Phoronix]() Topics: [Linux Kernel](), [Linux]() Tags: [adoption](), [amd](), [attack-surface](), [desktop-linux](), [i386](), [intel](), [kernel](), [linux](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [lts](), [open-source-graphics](), [patches](), [phoronix](), [phoronix-test-suite](), [retirement](), [ubuntu-benchmarks](), [ubuntu-hardware](), [x86](), [x86-64]() ### AI overview Linux kernel developers have proposed patches to begin removing the x32 ABI by marking it as BROKEN. The proposal cites limited adoption and security concerns; removal would follow after this year's last LTS kernel. ### Source excerpt Linux developers are once again considering the removal of the Linux x32 ABI... ## A new Raspberry Pi Desktop release is finally available for x86-64 DevFeed: [A new Raspberry Pi Desktop release is finally available for x86-64]() Original publisher: [Read original article]() Author: jzb Published: 2026-10-07T13:26:25Z Content type: news Language: en Sources: [LWN.net]() Topics: [Linux Mint](), [version]() Tags: [debian](), [raspberry-pi-os](), [update](), [x86-64]() ### AI overview Raspberry Pi OS Desktop has been released for x86-64, based on Debian 13 (Trixie). The release moves from 32-bit to 64-bit Debian; Apple Silicon support remains experimental. ### Source excerpt Simon Long has announced a long-awaited release of Raspberry Pi OS, based on Debian 13 ("trixie"), for x86-64 systems. We managed to find the time to update the Desktop for the Buster and Bullseye releases of Debian, but then we all just got too busy with other things, and, while we left the Bullseye version on the website for anyone who wanted it, we simply didn't have time to release any newer versions. But people kept on asking for it - we get two or three emails every week asking when the PC Desktop will be updated, and we haven't had an answer, because we honestly didn't know when we might get a chance to do it. We've continually tried to allocate time to be able to work on this, but it hasn't been easy. [...] Earlier this year, we (or rather Serge) finally got the latest version of the Desktop running on top of a Debian Trixie image. It's now based on 64-bit Debian (the amd64 architecture) rather than the older 32-bit version, as Debian itself has stopped supporting 32-bit for PC architectures. This shouldn't be a major problem - most PCs made in the last 15 years or so will quite happily run the 64-bit version of Debian, as will most Intel-based Macs. (Debian support for Apple Silicon is still experimental, so unfortunately those of you with the latest and greatest shiny fruit products will not be able to run this.) ## Kage: Google Experimenting With Linux Driver Isolation Using In-Kernel LFI Sandboxes DevFeed: [Kage: Google Experimenting With Linux Driver Isolation Using In-Kernel LFI Sandboxes]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-10-07T12:50:16Z Content type: news Language: en Sources: [Phoronix]() Topics: [Linux](), [Linux Kernel](), [IPython]() Tags: [desktop-linux](), [driver](), [kernel](), [linux](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [llvm](), [network](), [nvme](), [open-source-graphics](), [phoronix](), [phoronix-test-suite](), [sandboxes](), [stanford](), [technology](), [ubuntu-benchmarks](), [ubuntu-hardware](), [virtio](), [wifi](), [x86](), [x86-64]() ### AI overview Google engineers are developing Kage, a Linux kernel subsystem that isolates device drivers in in-kernel sandboxes using LLVM's Lightweight Fault Isolation. Prototypes have run NVMe, network, and Wi-Fi drivers in sandboxed environments; further performance testing is needed, and GPU driver sandboxing remains under exploration. Google may consider Kage for Android device drivers. ### Source excerpt Google engineers are experimenting with Linux kernel device driver isolation using in-kernel sandboxes leveraging LLVM's Lightweight Fault Isolation (LFI) functionality... ## Zig 0.17 released DevFeed: [Zig 0.17 released]() Original publisher: [Read original article]() Author: jzb Published: 2026-10-03T11:31:18Z Content type: release Language: en Sources: [LWN.net]() Topics: [Zig]() Tags: [compilation](), [linker](), [linux](), [programming](), [release](), [server](), [system](), [x86](), [x86-64](), [zig]() ### AI overview Zig 0.17 was released after five months of work involving 206 contributors and 925 commits. The release reworks the build system, introduces the Build Server Protocol, and enhances the ELF linker, with incremental compilation expected to work for everyone on x86_64 Linux. ### Source excerpt Version 0.17 of the Zig programming language has been released. This release features 5 months of work: changes from 206 different contributors, spread among 925 commits. Originally predicted to be shorter, this release cycle ended up [being] substantial, with the Build System reworked, including the introduction of the Build Server Protocol, and the ELF Linker enhanced to the point where we expect Incremental Compilation to work for everyone on x86_64-linux. LWN last covered Zig in December 2025. ## Why is there no Windows hot-patching support for other architectures like 32-bit ARM and MIPS? DevFeed: [Why is there no Windows hot-patching support for other architectures like 32-bit ARM and MIPS?]() Original publisher: [Read original article]() Author: Raymond Chen Published: 2026-10-02T14:00:00Z Content type: article Language: en Sources: [Raymond Chen]() Topics: [Windows](), [NVFP4]() Tags: [architectures](), [old-new-thing](), [other](), [patching](), [windows](), [x86](), [x86-64]() ### AI overview Windows hot-patching supports x86-32, x86-64, 64-bit ARM, and Itanium. MIPS, Alpha AXP, PowerPC, and SH-3 predate the feature, while 32-bit ARM lacked support because hot-patching is a Windows Server feature and there was no Windows Server version for that architecture. ### Source excerpt They either predate hot-patching or never needed it. The post Why is there no Windows hot-patching support for other architectures like 32-bit ARM and MIPS? appeared first on The Old New Thing. ## Demoting i686 Windows targets to std-only DevFeed: [Demoting i686 Windows targets to std-only]() Original publisher: [Read original article]() Author: Mateusz MikuĊ‚a, Ralf Jung Published: 2026-10-02T00:00:00Z Content type: release Language: en Sources: [Rust]() Topics: [Cross-Compilation](), [toolchain](), [Continuous integration](), [MSVC]() Tags: [c-plus-plus](), [ci](), [cross](), [llvm](), [rust](), [target](), [toolchain](), [toolchains](), [x86](), [x86-64]() ### AI overview Rust 1.100 will demote its i686 Windows MSVC and GNU targets to tiers without host tools. Standard library builds will remain available, and the MSVC target will continue to receive CI testing. Developers will need to cross-compile 32-bit Windows binaries from a supported host; other 32-bit platforms are unaffected. ### Source excerpt With Rust 1.100.0, the following changes to 32-bit Windows targets will happen: i686-pc-windows-msvc Tier 1 with host tools target will be demoted to Tier 1 without host tools. i686-pc-windows-gnu Tier 2 with host tools target will be demoted to Tier 2 without host tools. Builds of the standard library will continue to be distributed, but host tools such as the compiler will be no longer available. i686-pc-windows-msvc as a Tier 1 target still undergoes CI testing. To build 32-bit Windows binaries, cross-compiling from a still-supported host toolchain (such as a 64-bit Windows ones) will be required from now on. Background Desktop and Server 32-bit only x86 CPUs are no longer sold for over 15 years, and general 32-bit Windows support has ended in October 2025. This means that the development platforms these targets are meant for hardly exist these days, and even if they do exist they typically aren't capable enough for development. Even on the modern x86_64 hardware, building i686 Windows toolchains has proven to be problematic. We have encountered compiler binaries crashing when built with the i686 MSVC target, and the GNU C++ toolchain failing with OOMs during LLVM build. Considering all these things, cross-compiling these targets from a better supported one is what we have found to be the best solution forward. As part of that, we stopped producing host tools for these targets. For the time being, the prebuilt standard library is still available, and in case of i686-pc-windows-msvc still tested on CI. What Changes? After Rust 1.100, it will no longer be possible to install toolchains on 32-bit Windows hosts. We recommend cross-compiling from a still-supported host (such as a 64-bit Windows toolchain) instead. Other 32-bit platforms are not impacted by this change. For more details about these demotions, see RFC 3999 for i686-pc-windows-msvc demotion, and MCP 1020 for i686-pc-windows-gnu demotion. ## Windows on AArch64 also provides for hot-patching, but it's much simpler than on x86 DevFeed: [Windows on AArch64 also provides for hot-patching, but it's much simpler than on x86]() Original publisher: [Read original article]() Author: Raymond Chen Published: 2026-09-30T14:00:00Z Content type: article Language: en Sources: [Raymond Chen]() Topics: [x86](), [Windows]() Tags: [old-new-thing](), [other](), [patch](), [signing](), [trampoline](), [windows](), [x86-64]() ### AI overview Windows uses a 12-byte patch space before each AArch64 function to hold a three-instruction trampoline for hot-patching. Because AArch64 instructions are fixed at four bytes, the function entry can be redirected with one branch instruction, and the patch avoids the instruction-pointer alignment concern present with variable-length x86 instructions. The post also notes that the entry instruction is likely PACIBSP, which signs the return address. ### Source excerpt Fixed-length instructions makes it a much easier task. The post Windows on AArch64 also provides for hot-patching, but it's much simpler than on x86 appeared first on The Old New Thing. ## C++26 standardizes breakpoints and debugger detection DevFeed: [C++26 standardizes breakpoints and debugger detection]() Original publisher: [Read original article]() Author: Sandor Dargo Published: 2026-09-29T22:00:00Z Content type: article Language: en Sources: [Sandor Dargo's Blog]() Topics: [c/c++](), [x86](), [gdb]() Tags: [asm](), [bare-metal](), [breakpoint](), [c-plus-plus](), [c-plus-plus-26](), [clang](), [debugger](), [debugging](), [dev](), [gcc](), [i386](), [libstdc-plus-plus](), [linux](), [x86-64]() ### AI overview C++26 adds standardized functions for triggering breakpoints and checking whether a debugger is attached. The article explains their behavior, platform-specific implementation choices, and how replaceability supports freestanding environments where operating-system debugger detection may be unavailable. ### Source excerpt If you've ever needed to hit a breakpoint programmatically in C++, you've probably written something like this: #if defined(_MSC_VER) __debugbreak(); #elif defined(__clang__) __builtin_debugtrap(); #elif defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__)) __asm__ volatile("int3"); #else raise(SIGTRAP); #endif Every major C++ project reinvents this wheel. B... ## New FUTEX Syscalls Back To Being Worked On For Helping Valve's ARM64 Gaming Ambitions DevFeed: [New FUTEX Syscalls Back To Being Worked On For Helping Valve's ARM64 Gaming Ambitions]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-25T22:42:16Z Content type: news Language: en Sources: [Phoronix]() Topics: [Linux Kernel](), [Kernel](), [Emulator](), [io\_uring](), [race-condition](), [x86](), [x86-64](), [Open Source]() Tags: [desktop-linux](), [emulator](), [igalia](), [kernel](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-kernel](), [linux-performance](), [linux-server-benchmarks](), [open-source](), [open-source-graphics](), [phoronix](), [phoronix-test-suite](), [race-condition](), [ubuntu-benchmarks](), [ubuntu-hardware](), [x86](), [x86-64]() ### AI overview Igalia has posted an updated version of Linux kernel patches for the FUTEX get_robust_list2 and set_robust_list2 system calls. The work addresses shortcomings affecting FEX-Emu and other emulation layers supporting ARM64 gaming, and follows fixes for a race condition and VDSO changes. ### Source excerpt Going back to last year the Igalia open-source consulting firm has been working on enhancing the Linux kernel to help Steam Play gaming on ARM64 and ensuring the FEX emulator is operating efficiently for x86/x86_64 games running on the likes of the Steam Frame. After other kernel work in recent months, there's finally an updated round of the FUTEX get_robust_list2 and set_robust_list2 system call patches... ## Approaching A 10 Second Linux Kernel Build DevFeed: [Approaching A 10 Second Linux Kernel Build]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-25T14:46:26Z Content type: news Language: en Sources: [Phoronix]() Topics: [Linux Kernel](), [build times](), [Linux](), [x86-64](), [builds]() Tags: [build-times](), [compilation](), [desktop-linux](), [improvements](), [incremental](), [linux](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-kernel](), [linux-performance](), [linux-server-benchmarks](), [open-source-graphics](), [phoronix](), [phoronix-test-suite](), [productivity](), [ubuntu-benchmarks](), [ubuntu-hardware](), [x86-64]() ### AI overview A Linux kernel build is approaching ten seconds on x86-64 systems. Current hardware and software improvements have reduced clean builds to roughly 15 seconds, while allmodconfig builds can take under two minutes. A patch series targeting Kbuild bottlenecks is reported to improve kernel and incremental build times further. ### Source excerpt The coffee window is closing. Going back many years with the time it's taken to compile the Linux kernel has been a well known opportunity for a coffee break or even eating a meal during the lengthy Linux kernel build process. Even when the Linux kernel was much smaller than it is today, with the hardware at the time it would often be a very time consuming process... Thus incredible to think that we are now on the horizon of a ten second clean, default kernel build on Linux x86_64. ## Go's Improving SIMD Support, Platform-Independent SIMD Interface DevFeed: [Go's Improving SIMD Support, Platform-Independent SIMD Interface]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-25T09:50:22Z Content type: news Language: en Sources: [Phoronix]() Topics: [Go Language](), [Programming](), [Programming language](), [API](), [cpu](), [Arm](), [x86-64](), [Library]() Tags: [api](), [apis](), [arm](), [avx](), [avx2](), [cpu](), [desktop-linux](), [developers](), [experimental](), [go](), [go-language](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [open-source-graphics](), [phoronix](), [phoronix-test-suite](), [platform](), [portable](), [processors](), [programming](), [programming-language](), [simd](), [sve](), [ubuntu-benchmarks](), [ubuntu-hardware](), [wasm](), [x86](), [x86-64]() ### AI overview Go is expanding its experimental SIMD support across x86-64, ARM64, and WebAssembly. Go 1.27 added a portable, platform- and vector-size-agnostic SIMD interface, with Arm SVE support and additional operations planned for Go 1.28. ### Source excerpt A new blog post published on Thursday covers the experimental support for SIMD with the Go programming language. This expanding Go SIMD support also includes a platform-independent API for making use of SIMD with modern processors... ## When to choose x86-64 vs aarch64 DevFeed: [When to choose x86-64 vs aarch64]() Original publisher: [Read original article]() Author: Ahmed Darwich Published: 2026-09-25T00:00:00Z Content type: article Language: en Sources: [PlanetScale]() Topics: [Arm](), [x86-64](), [cpu](), [Database](), [PlanetScale](), [x86](), [cloud-infrastructure]() Tags: [architecture](), [architectures](), [arm](), [aws](), [chip](), [chips](), [cloud](), [cpu](), [engineering](), [google](), [graviton](), [low-power](), [neki](), [performance](), [postgres](), [power](), [processor](), [x86](), [x86-64]() ### AI overview This article explains how x86-64 and Arm server architectures differ for PlanetScale Postgres and Neki databases. It covers vCPU definitions, hyperthreading, power efficiency, and how workload concurrency affects performance when choosing a cloud database architecture. ### Source excerpt ARM and x86 can give you different performance at the same vCPU count. Here's what differs, what to measure, and how to choose. ## Linux 7.3-rc4 Includes Fixes for x86, Drivers, Filesystems, Networking, and Tooling DevFeed: [Linux 7.3-rc4 Includes Fixes for x86, Drivers, Filesystems, Networking, and Tooling]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-20T21:25:38Z Content type: news Language: en Sources: [Phoronix]() Topics: [Linux](), [Code](), [Filesystems](), [Large Language Model](), [btrfs](), [Network](), [x86](), [Developer Tools]() Tags: [architecture](), [btrfs](), [bug](), [code](), [desktop-linux](), [filesystem](), [linux](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [llms](), [networking](), [open-source-graphics](), [patches](), [phoronix](), [phoronix-test-suite](), [tooling](), [ubuntu-benchmarks](), [ubuntu-hardware](), [x86-64]() ### AI overview Linux 7.3-rc4 includes fixes for x86 and x86_64, new XPad controller support, Btrfs bugs, a silent user-space data-loss bug, filesystems, networking, and tooling. The article also notes that LLMs helped identify some error-path cleanup issues. ### Source excerpt Linus Torvalds announced the release today of Linux 7.3-rc4. As usual for recent months, the fixes continue to be quite heavy and scattered all over the place driven in large part by AI/LLMs spotting various code defects. Overall though Linus Torvalds isn't too worried about Linux 7.3-rc4... ## AMD Strix Halo Enjoys Some Performance Gains On Ubuntu 26.10, Especially With amd64v3 DevFeed: [AMD Strix Halo Enjoys Some Performance Gains On Ubuntu 26.10, Especially With amd64v3]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-18T14:00:00Z Content type: article Language: en Sources: [Phoronix]() Topics: [Ubuntu](), [x86](), [Security Operations Center](), [Linux]() Tags: [amd](), [amd64v3](), [benchmarks](), [beta](), [desktop-linux](), [efficiency](), [experimental](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [next](), [open-source-graphics](), [performance](), [phoronix](), [phoronix-test-suite](), [power](), [radeon](), [release](), [systems](), [ubuntu](), [ubuntu-26-04](), [ubuntu-26-10](), [ubuntu-benchmarks](), [ubuntu-hardware](), [ubuntu-linux](), [upgrades](), [x86](), [x86-64](), [x86-64-v3]() ### AI overview This performance review compares Ubuntu 26.04 LTS with Ubuntu 26.10 on AMD Strix Halo systems, including tests using experimental amd64v3 packages. It reports performance and power-efficiency gains on hardware such as the Framework Desktop with Ryzen AI Max+ 395 and Radeon 8060S graphics. ### Source excerpt Ahead of next week's Ubuntu 26.10 beta release I have been testing the "Stonking Stingray" on a variety of systems. Ubuntu 26.10 is performing well overall with some nice upgrades over Ubuntu 26.04 LTS, especially if opting to use the new snapshot/daily ISOs of Ubuntu 26.10 in amd64v3 form for x86_64-v3 packages. In today's tests are a look at the performance benefits of Ubuntu 26.10 on an AMD Ryzen AI Max+ "Strix Halo". ## AlmaLinux 9.9 Beta Now Available! DevFeed: [AlmaLinux 9.9 Beta Now Available!]() Original publisher: [Read original article]() Author: Eduard Abdullin The Release; Automation Engineer Published: 2026-09-17T00:00:00Z Content type: release Language: en Sources: [AlmaLinux]() Topics: [releases](), [Security](), [virtualization](), [Compiler](), [gcc](), [LLVM](), [Rust](), [Node.js](), [PHP](), [qemu](), [SELinux](), [toolchain]() Tags: [amd](), [beta](), [compiler](), [gcc](), [intel](), [llvm](), [node-js](), [php](), [qemu](), [release](), [rust](), [security](), [selinux](), [x86](), [x86-64]() ### AI overview AlmaLinux announces the availability of AlmaLinux 9.9 Beta, "Chartreuse Bobcat," for Intel/AMD, ARM64, IBM PowerPC, and IBM Z. The release includes updated compiler toolsets, module streams, virtualization components, graphics, and security software. It also upgrades fapolicyd to version 2.0.1 and asks users to test the beta and report bugs before production release. ### Source excerpt Hello Community! The AlmaLinux OS Foundation is announcing the availability of AlmaLinux 9.9 Beta "Chartreuse Bobcat" for all supported architectures: Intel/AMD (x86_64) ARM64 (aarch64) IBM PowerPC (ppc64le) IBM Z (s390x) Beta ISOs are available at vault.almalinux.org. A usual reminder: this is a BETA release. It should not be used for production installations. The provided upgrade instructions should not be used on production machines unless you don't mind if something breaks. If you are looking to see how things are going to work in stable, you are on the right track. [Next page]()