Go: ARM64 Gets a Memory Access Upgrade

Transcript

Hey there, fellow Go enthusiasts! Welcome back to another episode of the Go podcast. I'm your host, and wow, what a beautiful Monday morning this is - February 23rd, 2026. I hope you're settling in with your favorite caffeinated beverage because we've got some really interesting low-level improvements to talk about today.

You know, sometimes the most fascinating changes in Go aren't the big flashy features that make headlines. Sometimes it's the quiet, thoughtful work happening deep in the compiler that really shows the craftsmanship of this language. And today's episode is exactly that kind of story.

So let's dive right into what happened in the Go codebase. We had one commit land today, but it's a really neat one that showcases how the Go team is constantly refining performance across different processor architectures.

Alexander Musman has been working on something pretty cool in the ARM64 assembly world. He added support for FMOVQ instructions when working with global addresses. Now, if you're not deeply familiar with assembly - and honestly, most of us aren't, and that's totally fine - let me break this down in a way that actually makes sense.

FMOVQ is basically an instruction that moves data around on ARM64 processors. Think of it like a specialized delivery truck that's really good at moving specific types of cargo. Up until now, this particular "delivery truck" couldn't handle pickups and drop-offs at global addresses - those are essentially memory locations that your entire program can access from anywhere.

What Alexander did was teach the Go compiler how to generate the right sequence of instructions to make this work. The solution uses what's called an R_ADDRARM64 relocation with a three-step dance: ADRP, then ADD, then FMOVQ. It's like giving our delivery truck a GPS system and a proper route to reach those global addresses.

Now, here's what I find really thoughtful about this change - Alexander notes in the commit message that currently, there aren't any global addresses that are known to be aligned to 16 bytes. This is the kind of forward-thinking work I absolutely love to see. They're building infrastructure for scenarios that might not be common today, but could become important as the language and its use cases evolve.

The changes touched two key files: the ARM64 assembly test data and the core ARM64 assembler code. It's a small change in terms of lines of code - we're talking about adding just a couple of lines to the assembler and six lines to the test suite. But the impact on ARM64 performance and capability could be significant for certain workloads.

What really strikes me about this commit is the review process. Keith Randall was heavily involved in the review, and Cherry Mui also signed off on it. This shows how even these detailed, architecture-specific changes get thorough attention from the core team. Nobody's working in isolation here.

Today's Focus: If you're working with Go on ARM64 systems, especially if you're doing performance-critical work, keep an eye on how these kinds of improvements might benefit your applications. You probably won't need to change any of your Go code to take advantage of this - that's the beauty of compiler improvements. Your existing code just gets better.

And for those of you interested in contributing to Go, this is a perfect example of how valuable deep, technical contributions can be. Not every contribution needs to be a new language feature or a massive API change. Sometimes the most impactful work happens in the places most developers never see.

That's a wrap for today's episode! Keep building amazing things with Go, keep learning, and remember - every improvement, no matter how technical or small, makes the entire ecosystem better for everyone. I'll catch you tomorrow with more Go goodness. Until then, happy coding!