# compiler Published articles for compiler. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Bringing Correctly Rounded Math to Production with LLVM-libc DevFeed: [Bringing Correctly Rounded Math to Production with LLVM-libc]() Original publisher: [Read original article]() Author: Cody Miller, Tue Ly, Michael Jones Published: 2026-09-16T22:09:50Z Content type: article Language: en Sources: [C++ Team Blog]() Topics: [LLVM](), [Support](), [C++]() Tags: [c-plus-plus](), [compiler](), [llvm](), [msvc]() ### AI overview This guest post explains LLVM-libc's design philosophy of portability and modularity, and discusses its math functions, including their use by MSVC for compile-time evaluation and runtime execution when /Zc:cmath is enabled. ### Source excerpt As we mentioned in the last cmath blog post, MSVC is using LLVM-libc for compile-time evaluation and runtime execution of math functions when /Zc:cmath is enabled. I invited LLVM-libc contributors Michael Jones and Tue Ly to write a guest blog post about how they've achieved what they've achieved. This is that blog post! I hope [...] The post Bringing Correctly Rounded Math to Production with LLVM-libc appeared first on C++ Team Blog. ## Size-Specialized Memory Allocation DevFeed: [Size-Specialized Memory Allocation]() Original publisher: [Read original article]() Author: Michael Matloob Published: 2026-09-16T00:00:00Z Content type: article Language: en Sources: [The Go Blog]() Topics: [Go](), [optimize]() Tags: [collector](), [compiler](), [go](), [performance](), [spans]() ### AI overview Go 1.27 introduces size-specialized allocation functions for allocations smaller than 80 bytes. The change makes those allocations up to 20-30% faster and can improve allocation-heavy programs by up to 1%. ### Source excerpt Go 1.27 improves performance of small allocations using size-specialized allocation functions. ## How to Write a Linux Kernel Module That Actually Builds DevFeed: [How to Write a Linux Kernel Module That Actually Builds]() Original publisher: [Read original article]() Author: Chris Roy Published: 2026-09-15T21:10:57Z Content type: tutorial Language: en Sources: [freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More]() Topics: [Kernel](), [Linux](), [modules](), [Compiler](), [Secure Boot]() Tags: [compiler](), [kernel](), [linux](), [linux-kernel](), [module](), [secure-boot](), [tutorial]() ### AI overview This tutorial explains how to build and load a Linux kernel module, including the generated object files, metadata, symbols, debug information, required kernel headers and compiler setup, and common Secure Boot and kernel lockdown restrictions. ### Source excerpt A Linux kernel module is a small piece of code that can be loaded into the running kernel without rebuilding the entire kernel. That sounds simple enough, but even a minimal module produces a surprisi ## Fedora 45 Beta Released With KMSCON Console, GNOME 51 & Other Updates DevFeed: [Fedora 45 Beta Released With KMSCON Console, GNOME 51 & Other Updates]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-15T14:30:08Z Content type: news Language: en Sources: [Phoronix]() Topics: [Fedora](), [Linux]() Tags: [announcement](), [compiler](), [desktop-linux](), [linux](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [open-source-graphics](), [phoronix](), [phoronix-test-suite](), [release](), [ubuntu-benchmarks](), [ubuntu-hardware](), [update]() ### AI overview Fedora 45 Beta has been released with KMSCON replacing the in-kernel console, GNOME 51, Stratis Storage support in Anaconda, stricter security defaults, reproducible package builds, and updates to core development tools and libraries. A final release is planned for 20 October, with 27 October as a fallback date. ### Source excerpt The beta release of Fedora 45 is out today and right on schedule for this wonderful Linux distribution... ## Generating Java bytecode: Write yourself a compiler, Part V DevFeed: [Generating Java bytecode: Write yourself a compiler, Part V]() Original publisher: [Read original article]() Published: 2026-09-14T22:00:00Z Content type: tutorial Language: en Sources: [Tomasz Nurkiewicz around Java and concurrency]() Topics: [Java](), [Compiler](), [Programming]() Tags: [bytecode](), [compiler](), [file](), [go](), [interpreter](), [java](), [jvm](), [virtual-machine](), [writing-compiler]() ### AI overview This tutorial explains how to extend a toy-language compiler to emit valid JVM bytecode in a .class file that can run on the Java Virtual Machine. It introduces JVM instruction families for pushing integer values and explains how the constant pool stores constants and symbolic references for reuse. ### Source excerpt Last time we created a virtual machine for our toy language. I think you can agree that designing a language which barely recognizes expressions like 2 + 3w and building a brand-new virtual machine for it seems a bit tedious. So what about keeping our microscopic language for now, but running it on a real, production-ready, battle-proven virtual machine? Like the Java Virtual Machine? Our task for today is to emit JVM bytecode in the form of a valid .class file. That file can then be fed directly to the JVM to run our program. ## Linux 7.4 Could End Up Seeing Kernel Builds ~36% Faster, Incremental Builds ~70% Faster DevFeed: [Linux 7.4 Could End Up Seeing Kernel Builds ~36% Faster, Incremental Builds ~70% Faster]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-14T10:31:16Z Content type: news Language: en Sources: [Phoronix]() Topics: [Linux](), [build performance](), [build times](), [Arm](), [Compiler](), [Git](), [Artificial Intelligence]() Tags: [ai](), [arm](), [build-times](), [compiler](), [desktop-linux](), [git](), [linux](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [open-source-graphics](), [phoronix](), [phoronix-test-suite](), [ubuntu-benchmarks](), [ubuntu-hardware]() ### AI overview A second revision of Linux kernel patches could make full allmodconfig builds about 36% faster and incremental builds about 70% faster. The work, led by Lorenzo Stoakes of Arm, addresses single-threaded bottlenecks and includes fixes, an upstream rebase, and an optional parallel Rust compiler front end. The patches are being considered for inclusion in Linux 7.4. ### Source excerpt Earlier this month I wrote about a patch series posted to the Linux kernel mailing list that addressed a lot of "hideous code" to make Linux kernel builds faster. A number of single-threaded bottlenecks were tracked down and fixed within the Linux kernel thanks to the assistance of AI. A second revision of those patches hit the mailing list this morning and there is hope they could be upstreamed for Linux 7.4... ## Kotlin 2.4.20 Collection Checks and Experimental Context-Sensitive Resolution DevFeed: [Kotlin 2.4.20 Collection Checks and Experimental Context-Sensitive Resolution]() Original publisher: [Read original article]() Author: Andrii Dubovyk Published: 2026-09-14T06:32:51Z Content type: tutorial Language: en Sources: [ProAndroidDev - Medium]() Topics: [Kotlin](), [Compiler](), [Code]() Tags: [android](), [android-development](), [collections](), [compiler](), [experimental](), [features](), [kotlin](), [list](), [mobile-app-development](), [syntax](), [technology]() ### AI overview The article explains two Kotlin features: allDistinctBy and allEqualBy in Kotlin 2.4.20 for checking collection values, and experimental context-sensitive resolution introduced in Kotlin 2.2 to reduce repetition when the expected type is known. ### Source excerpt Kotlin 2.4.20 gives your collections opinions, and 2.2's compiler finally learns to read the room Some Kotlin features get a lot of attention when they arrive. Others are much less noticeable, but still make everyday code a little easier to write. Two examples of the latter are allDistinctBy/ allEqualBy in Kotlin 2.4.20 and context-sensitive resolution, which was introduced experimentally in Kotlin 2.2. allDistinctBy/ allEqualBy: A Simpler Way to Check Collections For years, checking whether all values in a collection were unique often looked something like this: val users = listOf( User(name = "A", age = 20), User(name = "B", age = 25), User(name = "C", age = 30) ) users.map { it.age }.distinct().size == users.size // true It works, but it creates another list, removes duplicates, counts the result, and then compares the sizes just to get a Boolean answer. Kotlin 2.4.20 adds a more direct way to express the same check: users.allDistinctBy { it.age } // true users.allEqualBy { it.age } // false allDistinctBy returns false as soon as it finds a duplicate, so it doesn't need to process the entire collection or create a separate Set. allEqualBy does the opposite: it checks whether all elements produce the same value when passed through the selector. Both functions work with Iterable, Sequence, and arrays. They use structural equality. For floating-point values, they follow Double.equals semantics, so NaN is considered equal to NaN, while -0.0 is different from 0.0. They're still @ExperimentalStdlibApi, so you'll need to opt in before using them in production code. The underlying allDistinct() and allEqual() requests have also been around in YouTrack for quite a while, which makes their appearance in the standard library feel long overdue. Context-Sensitive Resolution: Less Repetition in when The second feature is more about syntax. When the compiler already knows the type you're working with, you can sometimes leave out the type qualifier. Before: enum class Problem { ## Build Setup: Targets, Source Sets and buildSrc for tvOS in a Compose Multiplatform Fork DevFeed: [Build Setup: Targets, Source Sets and buildSrc for tvOS in a Compose Multiplatform Fork]() Original publisher: [Read original article]() Author: Sajid Ali Published: 2026-09-14T04:24:43Z Content type: tutorial Language: en Sources: [ProAndroidDev - Medium]() Topics: [compose-multiplatform](), [tvOS](), [Kotlin Multiplatform](), [Gradle]() Tags: [apple](), [build](), [compiler](), [compose-multiplatform](), [gradle](), [gradle-plugin](), [ios](), [jetbrains](), [multiplatform](), [source]() ### AI overview This tutorial explains the build setup for adding tvOS support to a Compose Multiplatform fork. It covers Kotlin Multiplatform targets, source-set organization shared between iOS and tvOS, and the build-layer work used to identify missing modules and dependencies. ### Source excerpt Compose Multiplatform on tvOS This series: Compose Multiplatform on tvOS My Journey Making Compose Multiplatform Work on tvOS, and What I Learned Build Setup: Targets, Source Sets and buildSrc for tvOS in a Compose Multiplatform Fork (this post) Rendering (coming soon) Siri Remote input (coming soon) Siri Remote trackpad (coming soon) Screen density and text input (coming soon) Porting tv-material (coming soon) The Gradle plugin and third-party libraries (coming soon) Maintaining the fork (coming soon) Building a real app on it (coming soon) Part 1 was why this fork exists. This one is the build layer, and it comes before any Compose code, because in Kotlin Multiplatform a target is not a flag you flip at the end. It decides which source sets compile, which dependencies resolve, which klibs get published, which linker flags get passed. Until the build knows about tvosArm64, nothing tells you what is missing. So the first commits were build files. Once the targets were on, the compiler listed what was missing, module by module, and I worked through that list. Source set layout on the tvos branch I started on a branch called tvos, based on upstream. Back then JetBrains called iOS "uikit" in this repository and the source set was uikitMain. Because tvOS is also UIKit underneath, it made sense to have a common source parent for both iOS and tvOS. But iOS was already being called uikit, so I chose uiKitCommonMain as the source set name and moved all the UIKit files there, keeping only the iOS specific files in uikitMain and putting the tvOS specific files in a new source set, tvosMain. The problem with this approach was how to keep up with upstream. I tried a symlink to the uikit source set, and then overriding the tvOS files in a separate target. The override worked but complicated the process. At that time my goal was to make it runnable on tvOS however possible, so we would have a proof of concept. So I did a lot of hacks in the tvos branch to make it runnable, and af ## Faster Starts, Less JavaScript Overhead DevFeed: [Faster Starts, Less JavaScript Overhead]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-09-14T00:00:00Z Content type: article Language: en Sources: [CodeName One]() Topics: [JavaScript](), [Compiler](), [Instrumentation]() Tags: [benchmarks](), [compiler](), [instrumentation](), [javascript](), [profiling]() ### AI overview The article describes startup-performance work in Codename One. It identifies launch delays caused by repeated screen-scale queries, theme scans, unnecessary synchronous dispatches, premature GC-park handshakes, and JavaScript suspension preparation. The fixes publish screen state atomically, avoid waiting when operations can proceed immediately, index theme keys, and improve instrumentation so profiling reveals hidden stalls. ### Source excerpt Codename One removes native startup waits, repeated style scans, and unnecessary JavaScript suspension. Profiles and compiler benchmarks expose costs that bundle size and frame rates miss. ## Kotlin Explicit Backing Fields: Encapsulation Tradeoffs and Downcasting Risks DevFeed: [Kotlin Explicit Backing Fields: Encapsulation Tradeoffs and Downcasting Risks]() Original publisher: [Read original article]() Author: Ehab Elwan Published: 2026-09-13T05:31:32Z Content type: opinion Language: en Sources: [ProAndroidDev - Medium]() Topics: [Kotlin](), [Code](), [Jetpack Compose]() Tags: [android](), [android-development](), [architecture](), [article](), [clean-code](), [code](), [compiler](), [kotlin](), [memory](), [software-architecture](), [stateflow]() ### AI overview This article compares Kotlin's traditional private mutable property plus public read-only wrapper with explicit backing fields. It explains that explicit backing fields can avoid an extra wrapper allocation, but because the underlying object remains mutable, an external downcast may bypass the intended read-only restriction and mutate internal state. ### Source excerpt Why eliminating the double-property boilerplate changes how we protect our architecture Image generated by AIDisclosure: This article was drafted by me and refined with the help of AI tools. If you have written Kotlin in the last few years, you are intimately familiar with the double-property boilerplate. Whether in Android ViewModels or general state holders, maintaining a private mutable property alongside a public read-only property is a chore we have all accepted in the name of strict encapsulation to prevent our internal state from being hijacked by outside classes. It makes the code significantly cleaner (and slightly more memory efficient). However, it fundamentally changes how we protect our state, moving from a physical object boundary to a simple type restriction. Let's look at the tradeoff. The Old Way: Wrapper Protection For years, the standard approach to encapsulating state has looked like this: class OldViewModel { // 1. The private mutable state private val _uiState = MutableStateFlow(UiState()) // 2. The public read-only state val uiState: StateFlow = _uiState.asStateFlow() } This is tedious to write, but it provides a strict architectural guarantee. When you call .asStateFlow(), Kotlin does not just change the type; it creates a brand new wrapper object in memory (ReadonlyStateFlow). While this physical barrier is fantastic for safety, it does mean you are incurring a minor memory allocation overhead by creating a secondary wrapper object for every exposed state. The New Way: Upcasting Explicit Backing Fields allow you to merge these two properties into one concise declaration, bypassing that extra memory allocation entirely: class NewViewModel { val uiState: StateFlow field = MutableStateFlow(UiState()) } Inside your class, the Kotlin compiler smart-casts the field so you can mutate it internally. Outside the class, the compiler restricts callers to the read-only StateFlow interface. It looks incredibly clean and saves an allocat ## HeyGen x Google Cloud: Bringing Avatar IV to TPUs DevFeed: [HeyGen x Google Cloud: Bringing Avatar IV to TPUs]() Original publisher: [Read original article]() Published: 2026-09-12T11:04:33.891311Z Content type: article Language: en Sources: [Google Developers Blog]() Topics: [Google](), [Cloud](), [Artificial Intelligence](), [Optimization](), [AI Infrastructure](), [Transformer](), [PyTorch](), [Compiler](), [Streaming](), [real-time](), [Hardware](), [API]() Tags: [ai](), [ai-infrastructure](), [api](), [cloud](), [code](), [compiler](), [engineering](), [generation](), [google](), [hardware](), [model](), [optimization](), [performance](), [pytorch](), [real-time](), [streaming](), [time](), [tpu](), [transformers](), [video]() ### AI overview HeyGen and Google Cloud describe porting the 18B+ parameter Avatar IV talking-head video generation pipeline to an eight-chip Trillium TPU host. Using torchax, JAX, XLA, FSDP sharding, Ulysses sequence parallelism, and custom Pallas kernels, the team improved performance by 1.86x for real-time chunked streaming while preserving output quality through strict quality gates. ### Source excerpt HeyGen ported their 18B+ parameter Avatar IV video generation model to Google Cloud's Trillium (v6e) TPUs via torchax and XLA, utilizing FSDP and Ulysses sequence parallelism across an eight-chip mesh. To achieve a 1.86x speedup for real-time streaming, the engineering team pipelined exposed all-to-all collectives, aligned sparse attention block sizes to eliminate mask padding, and bypassed softmax serial dependencies using a precomputed Cauchy-Schwarz upper bound. These custom Pallas kernel and compiler optimizations were deployed only after passing rigorous two-tier quality gates to guarantee byte-identical or mathematically equivalent pixel outputs. ## GCC 13.5 Released With 265+ Bug Fixes DevFeed: [GCC 13.5 Released With 265+ Bug Fixes]() Original publisher: [Read original article]() Author: Michael Larabel Published: 2026-09-11T09:47:06Z Content type: news Language: en Sources: [Phoronix]() Topics: [gcc](), [Compiler](), [bug](), [cpu](), [intel]() Tags: [amd](), [bug-fixes](), [bugs](), [compiler](), [cpu](), [desktop-linux](), [gcc](), [intel](), [linux-benchmarking](), [linux-hardware-benchmarks](), [linux-hardware-reviews](), [linux-how-to](), [linux-performance](), [linux-server-benchmarks](), [open-source-graphics](), [phoronix](), [phoronix-test-suite](), [production](), [release](), [ubuntu-benchmarks](), [ubuntu-hardware]() ### AI overview GCC 13.5 has been released with more than 265 bug fixes. It is the final planned point release for the GCC 13 branch, which is now closed to further development. ### Source excerpt For those continuing to rely on the GCC 13 compiler in production that debuted more than three years ago, GCC 13.5 released today with more than 265 bug fixes. GCC 13.5 also caps off the GCC 13 series as the last planned point release... ## Why is the x86 undefined instruction called ud2? Why 2? DevFeed: [Why is the x86 undefined instruction called ud2? Why 2?]() Original publisher: [Read original article]() Author: Raymond Chen Published: 2026-09-10T14:00:00Z Content type: article Language: en Sources: [Raymond Chen]() Topics: [x86](), [Assembly](), [Compiler](), [Exception](), [intel]() Tags: [compiler](), [exception](), [intel](), [old-new-thing](), [other](), [processor](), [x86]() ### AI overview The article explains why the x86 undefined instruction is called ud2. It describes how software used byte sequences that reliably raised an invalid opcode exception, how Intel later provided a standardized instruction, and how compiler output can use it to mark unreachable code and cause a deliberate crash. ### Source excerpt It came after ud0 and ud1. The post Why is the x86 undefined instruction called ud2? Why 2? appeared first on The Old New Thing. ## Koin Compiler 1.2: Compile-Time Safety for ALL Koin DSL DevFeed: [Koin Compiler 1.2: Compile-Time Safety for ALL Koin DSL]() Original publisher: [Read original article]() Author: Arnaud Giuliani Published: 2026-09-10T12:01:01Z Content type: release Language: en Sources: [Koin developers - Medium]() Topics: [Compiler](), [Kotlin](), [Gradle]() Tags: [compiler](), [dependencies](), [dependency-injection](), [gradle](), [implementation](), [koin](), [kotlin](), [kotlin-multiplatform]() ### AI overview Koin Compiler Plugin 1.2, with 1.2.1 as the latest patch, extends compile-time validation to Koin's reified, constructor, and classic lambda DSLs. It also adds visibility across Gradle modules, supports additional entry points, and provides one artifact for Kotlin 2.3.20 through 2.4.20 without requiring a DSL migration. ### Source excerpt Hello, dear Koin community 👋 I'm happy to share that Koin Compiler Plugin 1.2 is out, with 1.2.1 already available as the latest patch. Developer mascott unboxing new Koin Features!TL;DR Compile-time validation now works on the Koin application you already have, where before 1.2 it only covered code written specifically for the compiler plugin. Koin DSL -- All now covered! All Koin DSL: the plugin's reified DSL, Koin's constructor DSL (singleOf(::T)), and the classic lambda DSL (single { Foo(get()) }). Across Gradle modules: definitions are now visible two or more implementation hops away. More entry points: Ktor's install(Koin) and KoinApplication.withConfiguration(). One artifact for Kotlin 2.3.20 through 2.4.20. You get there with no migration to a new DSL, and nothing to rewrite. Let's go through what shipped. Covering now all Koin DSL Until now, compile-time safety only covered the plugin's own reified DSL, which means the two DSL styles you have most likely already written were invisible to it. val appModule = module { single() // checked singleOf(::UserRepository) // not checked before 1.2 single { AnalyticsHelper(get()) } // not checked before 1.2 } Three ways to declare a definition, and only the first was validated. If your UserRepository needed a Database that no module provided, your build passed and Koin threw at runtime. In 1.2, all three are validated. The two DSL styles get there differently. For the constructor DSL, the referenced constructor's parameters become real requirements, exactly like single(), and any named() qualifier you put on the registration is matched against the consumers that ask for it. The classic lambda DSL works differently. The plugin doesn't try to work out dependencies from free-form lambda code. What it validates instead are the get() calls you wrote inside the lambda, treated as ordinary resolution call sites. Before 1.2 those calls were skipped on purpose, because a hand-written get() is difficult to dis ## \[$\] Stabilizing Rust's never type DevFeed: [\[$\] Stabilizing Rust's never type]() Original publisher: [Read original article]() Author: daroc Published: 2026-09-08T13:34:38Z Content type: article Language: en Sources: [LWN.net]() Topics: [Rust](), [Compiler](), [Code](), [function]() Tags: [change](), [code](), [compiler](), [error](), [function](), [maintainers](), [optimize](), [rust]() ### AI overview The article explains Rust's never type, denoted by "!", and reports that it was stabilized after more than two years of work. It discusses the feature's practical benefits for optimizing generic code and its role in type inference, while noting a small breaking change to previous Rust editions. ### Source excerpt A function's return type is supposed to indicate the kind of data that it produces. Rust's "never" type, which is denoted by an exclamation mark ("!"), is the type the language uses to mark a function that never returns and other places where a value can never occur. For a long time, the never type was used internally by the compiler, but was considered an unstable feature. On August 24, after more than two years of work, Rust-compiler-contributor "waffle" finally managed to stabilize the type. It took so long, in part, because it involved a small breaking change to previous Rust editions, which the compiler maintainers needed to ensure did not impact much real code. ## Anthropic Formalized Fermat's Last Theorem in Lean, Shifting the Verification Challenge DevFeed: [Anthropic Formalized Fermat's Last Theorem in Lean, Shifting the Verification Challenge]() Original publisher: [Read original article]() Published: 2026-09-06T00:00:00Z Content type: opinion Language: en Sources: [Alex Korbonits]() Topics: [Lean](), [anthropic](), [Math and Logic]() Tags: [anthropic](), [compiler](), [formalized](), [research](), [statement](), [trust]() ### AI overview The article argues that Anthropic's machine-generated Lean proof of Fermat's Last Theorem changes the challenge from formalizing the theorem's statement to checking a very large proof artifact. It describes public build checks and an independent Rust-based Lean kernel re-check, while noting that the author has not read the patches used to complete that re-check. ### Source excerpt Anthropic formalized Fermat's Last Theorem in Lean in eleven days. It is the frontier I said in May was untouched, and the first result in this series where nobody had to trust the statement. The problem that replaced it is that 13 million lines is more than anyone can read. ## Updates on HEIR, the homomorphic encryption compiler project DevFeed: [Updates on HEIR, the homomorphic encryption compiler project]() Original publisher: [Read original article]() Published: 2026-09-04T18:53:40Z Content type: article Language: en Sources: [Jeremy Kun]() Topics: [homomorphic encryption](), [Compiler](), [Encryption](), [Cryptography](), [Machine learning](), [Inference](), [GitHub](), [bazel](), [Kaggle]() Tags: [bazel](), [ckks](), [compiler](), [cryptography](), [encryption](), [github](), [homomorphic-encryption](), [inference](), [kaggle](), [mathematics](), [ml](), [programming]() ### AI overview This companion article explains HEIR, a homomorphic encryption compiler that converts programs to operate directly on encrypted data. It discusses compiling pre-trained machine-learning models for private inference, describes the repository and setup, and reports an example involving encrypted credit-card fraud detection. ### Source excerpt On 2026-08-14 I published an article on the Google Security blog with an update on HEIR, our homomorphic encryption (HE) compiler. This is a companion article, in which I have no limits on word count or jargon, and I can feel free to be honest. So strap in. Assuming you won't read the linked corporate blog post, HEIR is a compiler that converts an input program to a program that operates directly on encrypted data. ## TinyGo 0.42 adds support for 87 Puya PY32 MCU variants and two EmbedFire boards DevFeed: [TinyGo 0.42 adds support for 87 Puya PY32 MCU variants and two EmbedFire boards]() Original publisher: [Read original article]() Author: Jean-Luc Aufranc (CNXSoft) Published: 2026-09-04T04:33:53Z Content type: news Language: en Sources: [CNX Software - Embedded Systems News]() Topics: [Go Language](), [Embedded Systems](), [Microcontroller](), [Compiler](), [Arm](), [Internet of things](), [LLVM]() Tags: [arm](), [article](), [code](), [compiler](), [development](), [development-board](), [devices](), [embedded-systems](), [firmware](), [go](), [gpio](), [guest-post](), [hardware](), [iot](), [llvm](), [mcu](), [microcontrollers](), [news](), [programming](), [puya](), [software-management](), [tooling]() ### AI overview TinyGo 0.42 adds support for the Puya PY32 family of 32-bit Arm microcontrollers, covering 87 MCU configurations and two EmbedFire development boards. The port includes startup code, linker scripts, GPIO, UART, and generated device-register definitions. ### Source excerpt CNXSoft: This is a guest post by Pavel Burgr, who recently added Puya PY32 MCU support to TinyGo 0.42, the latest version of the Go compiler for microcontrollers. We first covered TinyGo in 2019, and the project is still going strong with 17.7k stars, 1.1k forks, and 243 contributors. I just made a few edits and added illustrations and a few links to the article. TinyGo 0.42 adds support for the Puya PY32 family of 32-bit Arm microcontrollers. The new port includes startup code, generated device-register definitions, linker scripts, GPIO and UART support, and targets for 87 individual MCU configurations. It also includes board definitions for two inexpensive EmbedFire development boards available from AliExpress. The port was contributed by Pavel Burgr and merged through TinyGo pull request #5106. One motivation was to establish a solid, easy-to-use firmware platform for small IoT devices built around the Registry service and the BleRiot [...] The post TinyGo 0.42 adds support for 87 Puya PY32 MCU variants and two EmbedFire boards appeared first on CNX Software - Embedded Systems News. ## Amlogic A311Y3 Cortex-A78/A55 Edge AI system-on-module delivers up to 8 TOPS DevFeed: [Amlogic A311Y3 Cortex-A78/A55 Edge AI system-on-module delivers up to 8 TOPS]() Original publisher: [Read original article]() Author: Jean-Luc Aufranc (CNXSoft) Published: 2026-09-03T13:46:18Z Content type: article Language: en Sources: [CNX Software - Embedded Systems News]() Topics: [Embedded Systems](), [Artificial Intelligence](), [cpu](), [SOC](), [GPU](), [RISC-V](), [SDK](), [Android](), [Linux]() Tags: [2025](), [4g-lte](), [amlogic](), [android](), [arm](), [boardcon](), [camera](), [compiler](), [cortex-a55](), [cortex-a78](), [cpu](), [development-board](), [development-tools](), [display](), [edge-ai](), [edge-computing](), [embedded](), [embedded-systems](), [hardware](), [linux](), [npu](), [opencl](), [risc-v](), [rs485](), [som](), [specifications](), [vulkan]() ### AI overview The article examines Boardcon's CM311Y3 system-on-module, which uses the Amlogic A311Y3 octa-core SoC with Cortex-A78 and Cortex-A55 CPUs, an 8 TOPS NPU, LPDDR5 memory, eMMC storage, and interfaces for embedded applications. It also describes the module's development board, software support, and key specifications. ### Source excerpt Boardcon CM311Y3 system-on-module (SoM) is powered by an Amlogic A311Y3 octa-core Cortex-A78/A55 SoC with an 8 TOPS NPU and targets 4K video surveillance systems, AI edge computing devices, interactive terminals, enterprise thin clients, and autonomous robots. The module comes with up to 16GB LPDDR5 and up to 256 GB eMMC flash, exposes 210 pins through castellated edges, and a development board is also provided for evaluation and early software development. We don't often see new SoMs or SBCs based on Amlogic SoCs these days, so let's have a closer look. Boardcon CM311Y3 System-on-Module CM311Y3 specifications: SoC - Amlogic A311Y3 CPU 2x ARM Cortex-A78 cores @ 2.4GHx 6x ARM Cortex-A55 cores @ 2.0GHz RISC-V core for system control processing RISC-V core for Always-on power management and Sensor Hub GPU - Arm Mali-G625 MC1 with support for OpenGL ES 3.2, Vulkan 1.4, and OpenCL 3.0 VPU Video Decoder - H.264 up to [...] The post Amlogic A311Y3 Cortex-A78/A55 Edge AI system-on-module delivers up to 8 TOPS appeared first on CNX Software - Embedded Systems News. ## Build Hints That Fail Before the Build Server DevFeed: [Build Hints That Fail Before the Build Server]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-09-02T00:00:00Z Content type: article Language: en Sources: [CodeName One]() Topics: [Compiler](), [Java](), [configuration]() Tags: [autocomplete](), [build](), [compilation](), [compiler](), [configuration](), [java]() ### AI overview Codename One moves 87 common build hints into Java annotations so the compiler can catch misspelled names, incorrect value types, and unsupported options before builds reach the server. The change preserves the existing key-and-string format used by older projects and the build service. ### Source excerpt Codename One now exposes 87 common build hints as Java annotations, giving the compiler enough information to reject misspelled names, wrong types, and unsupported values before a build reaches the server. ## Your First Virtual Machine: Write yourself a compiler, Part IV DevFeed: [Your First Virtual Machine: Write yourself a compiler, Part IV]() Original publisher: [Read original article]() Published: 2026-08-24T22:00:00Z Content type: tutorial Language: en Sources: [Tomasz Nurkiewicz around Java and concurrency]() Topics: [Code](), [Programming](), [Programming language](), [Compiler]() Tags: [arithmetic](), [bytecode](), [clojure](), [code](), [compiler](), [cpu](), [feature](), [go](), [interpreter](), [reverse-polish-notation](), [stack](), [virtual-machine](), [vm](), [writing-compiler]() ### AI overview This tutorial explains how to build a virtual machine that reads and executes a binary intermediate representation. It covers the instruction loop, operand stack, arithmetic operations, postfix notation, and how the resulting executable compares with JVM files and .NET assemblies. ### Source excerpt In the previous article, we emitted an intermediate representation (IR) for our programming language that is easier to process than source code. However, we did not build a program that could read and execute that IR. Such a program is called a virtual machine. Technically, it's still an interpreter. But instead of interpreting source code, it interprets IR. Our IR is binary, compact, structured, and generally faster to interpret than the original source. Moreover, as you'll see later, the VM's instruction set can express programs that our source language cannot produce yet! ## Value Classes Still Need Compiler Sympathy DevFeed: [Value Classes Still Need Compiler Sympathy]() Original publisher: [Read original article]() Author: Johan Sjölén Published: 2026-08-24T00:00:00Z Content type: article Language: en Sources: [Inside Java]() Topics: [JDK 28](), [Optimization](), [Compiler]() Tags: [compiler](), [immutability](), [jdk-28](), [jep-401](), [jvm](), [openjdk](), [optimization](), [payload](), [profiling](), [project-valhalla](), [valhalla]() ### AI overview This article examines value classes as a preview feature in JDK 28 and explains how giving up object identity can enable JVM optimizations such as flattening and scalarization. It also describes limitations caused by representation changes, abstraction boundaries, mutability, and generic virtual calls. ### Source excerpt Declaring a value class is first and foremost a semantic decision. It tells our fellow programmers that its instances are defined entirely by their state and do not need identity. That clearer model is valuable in itself! The JVM's additional freedom to optimize how those values are represented is a welcome bonus. C2 can do amazing things with that freedom, but it cannot always recover information hidden behind abstraction boundaries. Profiling and inspecting the generated code remain the best ways to understand what is happening. To get the best results, we may still need to have a little sympathy for the compiler. ## Rust Function Overloading - Call for Experimentation DevFeed: [Rust Function Overloading - Call for Experimentation]() Original publisher: [Read original article]() Author: teor Published: 2026-08-19T00:00:00Z Content type: release Language: en Sources: [Inside Rust Blog]() Topics: [Rust](), [C++](), [Compiler](), [interoperability]() Tags: [c-plus-plus](), [compiler](), [interoperability](), [languages](), [rust](), [syntax]() ### AI overview The Rust Project is experimenting with function and method overloading for FFI bindings through the incomplete nightly "splat" compiler feature. The experiment aims to assess implementation complexity and improve interoperability with C++, while its design may change or be removed. ### Source excerpt In partnership with the Rust Foundation's Rust-C++ Interop Initiative, the Rust Project has been experimenting with function overloading for FFI bindings. This experiment is now at a stage where compiler and interop tool developers can start exploring function overloading. Stable Rust already supports a form of overloading using tuples and traits, but calling these overloaded functions looks strange, because the overloaded arguments have to be passed as a single tuple argument, like this: hypot((2.0, 3.0, 6.0)). Stable Rust also allows overloading of built-in operators with user-defined types, via traits like Add (the + operator) and Neg (the - value negation operator). We are running an unstable nightly Rust language experiment to answer questions like: How much overloading can we do with Rust's existing trait system? Could this help us call C++ from Rust ergonomically? In the tradition of yeet (to avoid bikeshedding), we are using basic syntax in the first stage of the experiment: the #[rustc_splat] attribute. Alternative syntaxes can be considered later, if the experiment generates useful outcomes. Experimental Function Overloading Rust nightly builds from 2026-07-31 onwards have experimental support for more ergonomic function and method overloading, using the incomplete "splat" compiler feature; if you're a compiler or interop tool developer, we encourage you to experiment with it! This experiment lets overloaded functions be called with separate arguments, like this: hypot(2.0, 3.0, 6.0). No double parentheses required! But type inference and type checking still happen as they would in a stable Rust overload. We are experimenting with splat to get a feel for the complexity of the implementation, and to see if it solves some language interoperability use cases. Like most Rust language experiments, this nightly feature has no RFC, and can change or be removed at any time. Experiment Design We expect the feature to change significantly in future, or to be replace ## Add the dependency graph to a Kotlin K2 migration checklist DevFeed: [Add the dependency graph to a Kotlin K2 migration checklist]() Original publisher: [Read original article]() Published: 2026-08-18T00:00:00Z Content type: tutorial Language: en Sources: [Koin - Cloud-Inject.io -Kotzilla]() Topics: [Kotlin](), [migration](), [Dependency injection](), [Graphs](), [Compiler](), [toolchain](), [Android Gradle Plugin](), [Compose]() Tags: [android-gradle-plugin](), [compiler](), [compose](), [dependency-injection](), [graph](), [kotlin](), [migration](), [rollback](), [toolchain](), [verification]() ### AI overview A practical checklist for Kotlin K2 migrations in projects that generate or validate dependency wiring. It recommends mapping the compiler and build toolchain, upgrading from a known compatibility matrix, cleaning and inspecting generated output, verifying dependency graphs across flavors and targets, testing runtime slices, and keeping rollback changes coherent. ### Source excerpt A K2 migration is usually planned around source compatibility and compiler diagnostics. Projects that generate or validate dependency wiring need another checklist: compiler plugin versions, generated sources, metadata compatibility, and graph verification on every target. Map the toolchain first Record the Kotlin plugin, Compose compiler plugin, KSP or annotation tooling, dependency-injection compiler plugin, Android Gradle plugin, and target libraries. Upgrade from a known matrix instead of selecting each latest version independently. [Next page]()