DEV Community: Yuna

Porting Intel SSE Intrinsics to ARM NEON in a Real C Project

Yuna — Fri, 21 Aug 2026 10:48:49 +0000

I recently wanted to see what actually happens when an existing C project containing Intel SSE intrinsics is ported to ARM64.

The usual example is straightforward:

__m128 r = _mm_add_ps(a, b);

becomes something like:

float32x4_t r = vaddq_f32(a, b);

But real porting work is rarely just a table of intrinsic names.

There are also:

compiler flags
floating-point semantics
reduction order
architecture-specific headers
build-system assumptions
fallback implementations

So I created a deliberately x86-specific C project and passed it through a tool I have been building called Miruri.

Miruri:

https://github.com/yuna-r/miruri

The interesting part was not only that the code compiled on ARM64, but also how the resulting implementation was structured.

The original project

The project is intentionally small:

intel-intrinsic-demo/
├── CMakeLists.txt
├── Makefile
├── include/
│   └── simd_math.h
└── src/
    ├── main.c
    └── simd_math.c

The implementation directly includes the Intel SSE header:

#include <xmmintrin.h>

There is no ARM compatibility code in the original source.

The project uses these SSE intrinsics:

_mm_loadu_ps
_mm_add_ps
_mm_mul_ps
_mm_storeu_ps
_mm_movehl_ps
_mm_shuffle_ps
_mm_add_ss
_mm_cvtss_f32

SIMD addition

The original implementation looks like this:

void simd_add4(
    const float a[4],
    const float b[4],
    float out[4])
{
    const __m128 va = _mm_loadu_ps(a);
    const __m128 vb = _mm_loadu_ps(b);
    const __m128 vr = _mm_add_ps(va, vb);

    _mm_storeu_ps(out, vr);
}

This is a classic 128-bit SSE operation.

Four 32-bit floating-point values are loaded, added in parallel, and stored.

The ARM64 implementation became:

const float32x4_t va = vld1q_f32(a);
const float32x4_t vb = vld1q_f32(b);

vst1q_f32(
    out,
    vaddq_f32(va, vb));

The mapping is very direct:

SSE	NEON
`_mm_loadu_ps`	`vld1q_f32`
`_mm_add_ps`	`vaddq_f32`
`_mm_storeu_ps`	`vst1q_f32`

Both operate naturally on four 32-bit floats in a 128-bit vector.

The resulting code kept both architectures

What I liked about the generated port was that it did not simply delete the x86 implementation.

Instead, it became something like this:

#if defined(__SSE__)

    /* SSE implementation */

#elif defined(__aarch64__) || defined(_M_ARM64)

    /* NEON implementation */

#else

    /* portable scalar implementation */

#endif

So an originally x86-only function effectively became a small portable SIMD abstraction.

The result now has three backends:

x86
 └─ SSE

ARM64
 └─ NEON

other architectures
 └─ scalar C

For a small library, I prefer this structure over pretending the Intel intrinsic API itself is portable.

For very large codebases with thousands of _mm_* calls, a compatibility layer such as sse2neon may make more sense.

Multiply-add was not converted to FMA

I also added this operation:

void simd_mul_add4(
    const float a[4],
    const float b[4],
    const float c[4],
    float out[4])
{
    const __m128 va = _mm_loadu_ps(a);
    const __m128 vb = _mm_loadu_ps(b);
    const __m128 vc = _mm_loadu_ps(c);

    const __m128 product = _mm_mul_ps(va, vb);
    const __m128 result = _mm_add_ps(product, vc);

    _mm_storeu_ps(out, result);
}

A tempting ARM implementation would use a fused multiply-add.

But the generated NEON code instead preserved the two operations:

const float32x4_t product =
    vmulq_f32(va, vb);

vst1q_f32(
    out,
    vaddq_f32(product, vc));

I think this is important.

The original SSE implementation performs:

multiply
↓
round
↓
add
↓
round

A fused multiply-add can perform:

multiply + add
↓
round once

That can produce slightly different floating-point results.

For many programs that difference is irrelevant.

For numerical software, codecs, simulations, databases, or HPC code, it may not be.

Porting SIMD code is therefore not always equivalent to selecting the shortest native instruction sequence.

Horizontal reduction was more interesting

I intentionally implemented a four-element sum using SSE1 operations:

float simd_sum4(const float a[4])
{
    const __m128 v = _mm_loadu_ps(a);

    const __m128 hi = _mm_movehl_ps(v, v);
    const __m128 pair_sum = _mm_add_ps(v, hi);

    const __m128 shuffled =
        _mm_shuffle_ps(
            pair_sum,
            pair_sum,
            _MM_SHUFFLE(1, 1, 1, 1));

    const __m128 total =
        _mm_add_ss(pair_sum, shuffled);

    return _mm_cvtss_f32(total);
}

The effective reduction order is approximately:

(a[0] + a[2]) + (a[1] + a[3])

The NEON version became:

const float32x4_t v =
    vld1q_f32(a);

const float32x2_t pair_sum =
    vadd_f32(
        vget_low_f32(v),
        vget_high_f32(v));

return vget_lane_f32(
    vpadd_f32(pair_sum, pair_sum),
    0);

The scalar fallback was also written as:

return (a[0] + a[2]) + (a[1] + a[3]);

That was interesting because the transformation preserved the basic pairwise reduction structure instead of reducing the vector in an unrelated order.

Floating-point addition is not associative, so this can matter.

Architecture-specific build flags matter too

The original CMake project deliberately contained:

if(CMAKE_C_COMPILER_ID MATCHES "Clang|GNU")
    target_compile_options(simd_math PRIVATE -msse)
endif()

That is perfectly reasonable on x86.

It is not reasonable on ARM64.

On Apple Silicon, Clang rejects it:

clang: error: unsupported option '-msse' for target 'arm64-apple-darwin'

The port therefore also had to modify the build logic:

if(CMAKE_C_COMPILER_ID MATCHES "Clang|GNU" AND
   CMAKE_SYSTEM_PROCESSOR MATCHES "^(x86_64|amd64|AMD64|i[3-6]86)$")
    target_compile_options(simd_math PRIVATE -msse)
endif()

This is a small example of something that becomes important in larger ports:

architecture dependencies are not limited to source files.

They also exist in:

CMake
Makefiles
configure scripts
compiler options
linker options
dependency selection

Testing the result

The demo contains a small self-test.

Input:

const float a[4] = {
    1.0f, 2.0f, 3.5f, -4.0f
};

const float b[4] = {
    10.0f, -2.0f, 0.5f, 8.0f
};

const float c[4] = {
    0.25f, 1.0f, -1.0f, 2.0f
};

Expected result:

a + b
= [11.000, 0.000, 4.000, 4.000]

a * b + c
= [10.250, -3.000, 0.750, -30.000]

sum(a)
= 2.500

On x86:

a + b = [11.000, 0.000, 4.000, 4.000]
a * b + c = [10.250, -3.000, 0.750, -30.000]
sum(a) = 2.500
SELFTEST: PASS

The same source tree was then built for:

Linux ARM64
→ ELF AArch64

macOS ARM64
→ Mach-O arm64

The Linux ARM64 sysroot was provisioned automatically.

What I learned

For simple operations, SSE-to-NEON conversion can look almost trivial:

_mm_loadu_ps
→ vld1q_f32

_mm_add_ps
→ vaddq_f32

_mm_mul_ps
→ vmulq_f32

_mm_storeu_ps
→ vst1q_f32

But that is only the visible part of the problem.

A serious port also has to consider:

instruction semantics
floating-point behavior
operation ordering
compiler flags
build configuration
fallback paths
ABI
target libraries
artifact architecture

That is where automated source transformation becomes more interesting than a simple intrinsic translation table.

This experiment only uses basic SSE.

Next I want to try more complicated examples involving:

SSE2
SSE4
AVX
AVX2
AVX-512

and see how far the same approach can be pushed.

I Built Miruri: A Tool That Ports Existing C/C++ Projects Across CPUs and Operating Systems

Yuna — Fri, 21 Aug 2026 10:46:56 +0000

CPUs and Operating Systems

I have been building a tool called Miruri.

The basic idea is simple:

Give it an existing software project and a target platform, and let it handle as much of the porting process as possible.

Repository:

https://github.com/yuna-r/miruri

It is still an alpha project, but it has reached the point where it can already do some surprisingly non-trivial things.

For example, I have used it to:

port Intel SSE code to ARM NEON
build Linux ARM64 binaries from an Apple Silicon Mac
build an Autotools terminal application for macOS
take a Linux/GNOME Python + GTK application and make it run as a macOS .app

That last one surprised me too.

What Miruri is trying to solve

Cross-compiling a clean, portable C project is usually not that difficult.

Real projects are different.

They contain things like:

x86 intrinsics
Windows APIs
Linux-specific APIs
architecture-specific compiler flags
platform GUI frameworks
graphics APIs
audio backends
plugins
generated files
custom build scripts
external SDK assumptions

A compiler can tell you that something failed.

It usually cannot tell you how the architecture of the project should change to make another platform a first-class target.

Miruri tries to operate at that level.

Instead of thinking only in terms of:

source file
→ compiler
→ binary

it treats porting more like:

existing project
      ↓
analyze platform assumptions
      ↓
construct target requirements
      ↓
choose a migration strategy
      ↓
modify an isolated copy
      ↓
build
      ↓
inspect artifacts

Basic usage

Miruri itself is written in Go.

Building it is intentionally simple:

git clone https://github.com/yuna-r/miruri.git
cd miruri

go build -o bin/miruri ./cmd/miruri

Check the local environment:

./bin/miruri doctor

List targets:

./bin/miruri targets

Then build a project for a target:

./bin/miruri build \
  --target macos-arm64 \
  path/to/project

For projects that actually require source changes:

./bin/miruri port \
  --target macos-arm64 \
  path/to/project

The port command allows broader source and build-system modifications.

It does not edit the original repository

One design decision I made early was that Miruri should not directly mutate the source repository being ported.

The flow is closer to:

original repository
        ↓
isolated working copy
        ↓
analysis and modifications
        ↓
build
        ↓
artifact collection

This matters a lot once automated repair is involved.

Compiler output, generated files, build caches, object files, and experimental changes should not leak back into the original source tree.

Accepted source changes can instead be represented as a patch.

AI is a repair engine, not the source of truth

Miruri can use Codex CLI for source-level repair.

But I did not want the system to become:

paste compiler error into AI
→ trust whatever comes back

The intended relationship is:

AI proposes changes

compiler validates syntax and ABI assumptions

linker validates symbol resolution

artifact inspection validates output architecture

A typical flow is:

analyze
↓
build
↓
failure
↓
extract diagnostics
↓
repair isolated source
↓
build again
↓
inspect artifact

For larger platform ports, the repair may involve more than changing a broken line.

It can add:

platform backends
compatibility code
conditional build logic
new entry points
GUI adapters
resource definitions

Linux sysroots are automatically provisioned

One annoying part of cross-compilation is building the target sysroot.

For example, compiling Linux ARM64 software from macOS may require:

headers
libc
crt objects
libgcc runtime
target libraries
multiarch paths

Miruri can provision this automatically.

For example:

./bin/miruri build \
  --target linux-arm64 \
  path/to/project

does not require manually supplying --sysroot.

Under the hood, Miruri can retrieve a matching OCI root filesystem and use it as build data.

It does not execute the container image.

The process is roughly:

OCI manifest
    ↓
select architecture
    ↓
download layers
    ↓
verify SHA-256 digests
    ↓
extract root filesystem
    ↓
validate toolchain/runtime files
    ↓
use as Clang sysroot

No Docker daemon or QEMU is required for this part.

The result is cached by content digest.

You can also prefetch it:

./bin/miruri sysroot ensure \
  --target linux-arm64

and inspect cached sysroots:

./bin/miruri sysroot list

Offline builds can reuse them:

./bin/miruri build \
  --target linux-arm64 \
  --offline \
  path/to/project

Build-system detection

Real-world OSS immediately forced me to support more than CMake.

Miruri currently understands:

CMake
Meson
Autotools
Make

Examples:

CMakeLists.txt
→ CMake

meson.build
→ Meson

configure.ac / configure.in
→ Autotools

For an Autotools Git checkout without a generated configure script, the flow can become:

configure.ac
↓
autoreconf
↓
configure
↓
make

Meson can also be managed by Miruri when it is missing from the host.

This grew organically from testing actual open-source projects.

Real-world test 1: nudoku

One project I tested was nudoku, a terminal Sudoku application.

It uses Autotools.

At first Miruri simply stopped with:

detected: autotools
no supported build system

So I added Autotools support.

After that, the same project could be built for Apple Silicon macOS.

That was the first point where Miruri started to feel less like a cross-compiler wrapper and more like a porting system.

Real-world test 2: a Linux GNOME GUI application on macOS

Then I tried something much more unreasonable.

I used Drawing, a Python + GTK drawing application designed for the GNOME/Linux desktop.

I ran:

./bin/miruri port \
  --target macos-arm64 \
  --codex-mode port \
  ~/src/drawing

This exposed one missing feature after another.

The process looked roughly like this:

Meson project
↓
Miruri did not support Meson
↓
add Meson adapter

Meson missing on host
↓
add managed Meson runtime

project produces no native executable
↓
support interpreted install artifacts

Linux install tree is not a macOS app
↓
add .app packaging

Linux Python launcher assumptions fail on macOS
↓
add compatibility rewrites

PyGObject runtime not visible
↓
resolve Homebrew Python runtime

bundle entry point shadows Python package
↓
fix package resolution

GTK GSettings schemas not visible
↓
adjust macOS GTK runtime environment

Eventually the Linux application opened on macOS as a real GUI application.

The GTK interface rendered correctly.

I could use:

menus
canvas drawing
text tools
fonts
checkboxes
radio buttons
Japanese UI
mouse interaction

Seeing a GNOME-oriented application show up as a macOS window after going through that pipeline was a fun moment.

Intel SSE to ARM NEON

Another experiment involved an intentionally x86-only C project.

The original source directly used:

#include <xmmintrin.h>

and operations such as:

_mm_loadu_ps
_mm_add_ps
_mm_mul_ps
_mm_shuffle_ps
_mm_storeu_ps

Miruri identified the architecture dependency and the resulting code gained separate backends:

#if defined(__SSE__)

    /* x86 */

#elif defined(__aarch64__)

    /* ARM NEON */

#else

    /* scalar */

#endif

For example:

_mm_add_ps(...)

became:

vaddq_f32(...)

and:

_mm_loadu_ps(...)

became:

vld1q_f32(...)

The same source tree could then produce:

Linux ARM64
→ ELF AArch64

macOS ARM64
→ Mach-O arm64

Compiler flags such as -msse also had to be made architecture-aware.

This is exactly the kind of issue Miruri is intended to find: architecture assumptions exist outside the C file too.

Project Graph and Target Contract

Internally, I am moving toward representing a project as capabilities rather than just files.

Conceptually:

Existing Project
      │
      ▼
Project Graph
      │
      ├── sources
      ├── build steps
      ├── resources
      ├── plugins
      ├── shaders
      └── platform capabilities
      │
      ▼
Target Contract
      │
      ▼
Strategy Planner
      │
      ├── native rebuild
      ├── source rewrite
      ├── compatibility layer
      ├── generated adapter
      └── unresolved blocker
      │
      ▼
Artifact Builder

For example:

#include <xmmintrin.h>

can be classified as a capability such as:

cpu.x86.intrinsics

A Windows-only GUI dependency could similarly become:

platform.windows.gui

This makes it possible to reason about a port at a higher level than individual compiler errors.

Artifact inspection matters

A successful compiler exit code is not enough.

Miruri inspects outputs such as:

ELF
Mach-O
PE
static archives

and verifies their architecture.

If the target is:

macOS ARM64

and the resulting Mach-O is actually x86_64, that should not be reported as a successful port.

Build results can also include metadata such as:

analysis.json
plan.json
build.log
manifest.json
sysroot.lock.json

so that the generated artifact has some provenance.

Cross-target artifacts are not automatically executed

Miruri currently avoids automatically running foreign target binaries during the porting process.

For example, when creating an ARM64 Linux ELF on macOS, it stops at:

compile
↓
link
↓
artifact inspection

instead of automatically launching it under an emulator.

That is intentional.

Once automatic execution is introduced, results can become dependent on:

emulator behavior
kernel behavior
drivers
graphics stack
audio stack
target services

I currently prefer to keep artifact production and target-runtime validation as separate stages.

What Miruri still cannot do

This is very much an alpha project.

There are many hard problems left.

Some examples:

Direct3D ↔ Vulkan ↔ Metal
shader translation
complex proprietary SDKs
driver dependencies
audio backend translation
full dependency resolution
semantic equivalence testing
bit-exact SIMD verification
production-quality standalone GUI packaging

Automatically making something compile is much easier than proving that the new implementation behaves exactly like the old one.

That is especially true for numerical and SIMD-heavy software.

The development process has been surprisingly fun

One thing I have enjoyed is testing Miruri with real open-source projects instead of only synthetic fixtures.

A fixture tends to fail in the way you expected.

Real software fails in ways you did not think about.

The development history has looked something like:

CMake works
↓
try real Autotools project
↓
add Autotools

try Meson project
↓
add Meson

try interpreted GUI app
↓
add staged install artifacts

try Linux GTK application on macOS
↓
add macOS application packaging

try x86 intrinsics
↓
add architecture-level porting logic

Each project reveals another assumption hidden inside the tool itself.

That has probably been the most useful form of testing.

Where I want to take it

Some areas I want to explore next:

SSE / AVX / AVX2 / AVX-512
→ NEON / SVE / SVE2

x86
→ RISC-V

x86
→ POWER

Windows GUI
→ macOS / Linux GUI

Direct3D
→ Vulkan / Metal

I am also interested in making semantic validation a much larger part of the system.

The hard part of automated porting is not generating different code.

The hard part is establishing that the different code still means the same thing.

Summary

Miruri is an experiment in automating software porting across CPUs and operating systems.

Repository:

https://github.com/yuna-r/miruri

At the moment it has infrastructure for:

CMake
Meson
Autotools
Make

Linux
macOS
Windows

x86_64
ARM64
RISC-V
POWER

and I have already used it for experiments including:

Intel SSE
→ ARM NEON

Autotools application
→ Apple Silicon macOS

and the slightly ridiculous one:

Linux/GNOME Python + GTK application
→ macOS .app
→ working GUI

There is still a lot to build, but the main question behind the project is simple:

How much of real software porting can we turn into a repeatable automated process?

That is what I am trying to find out.

I built RepoTrek: a terminal-first GitHub source browser in Rust

Yuna — Sun, 09 Aug 2026 03:05:58 +0000

I built RepoTrek, a terminal-first GitHub source browser written in Rust.

GitHub:

https://github.com/yuna-r/repotrek

crates.io:

https://crates.io/crates/repotrek

The basic idea is simple:

I wanted a comfortable way to deeply explore GitHub repositories without constantly switching between the browser, terminal, and editor.

RepoTrek is not intended to replace Git clients such as git, lazygit, tig, or gitui.

Its focus is different:

Git client
    ↓
operate on a repository

RepoTrek
    ↓
explore and read a repository

Why I built it

When reading open-source projects on GitHub, I often move through a sequence like this:

Code
 ↓
Blame
 ↓
Commit
 ↓
Diff
 ↓
File history
 ↓
Another file

GitHub's web interface is excellent, but when I spend a long time reading source code, I prefer staying in the terminal and using the keyboard.

So I started building a TUI specifically around source code exploration.

No clone required

You can open a repository directly from GitHub.

For example:

rust-lang/rust

or:

torvalds/linux

RepoTrek retrieves the repository information through GitHub APIs, so you don't need to clone the entire repository just to inspect it.

This is especially convenient for quickly looking through large projects.

Features

RepoTrek currently includes:

Repository tree browsing
Source code viewer with line numbers
Syntax highlighting
Dark / Light themes
Commit history
Commit diffs
File history
Git blame
Branch switching
File search
Repository-wide code search
Symbol navigation
Definition search
Pull Requests
Issues
GitHub Actions
Releases
Keyboard-based text selection and copy
Source/diff wrapping
HTML export for printing

The interface is designed to make moving between these views fast without leaving the terminal.

Source code browsing

The main view works like a terminal-native repository browser.

src/
├── app.rs
├── auth.rs
├── export.rs
├── highlight.rs
├── provider/
└── ui/

Open a file and RepoTrek displays it with line numbers and syntax highlighting.

Common languages such as Rust, Python, JavaScript, TypeScript, C/C++, Go, Java, YAML, TOML, JSON, Shell, HTML, CSS, and Markdown are recognized.

Unknown formats simply fall back to plain text.

Blame and file history

One feature I especially wanted was the ability to move naturally between:

source line
    ↓
blame
    ↓
commit
    ↓
diff
    ↓
history

The current source code often tells you what the program does.

History often tells you why it became that way.

That makes blame and file history important parts of RepoTrek rather than secondary features.

Commit diffs

Commit diffs include both old and new line numbers.

For example:

  81   81     fn example() {
  82          - old_code();
       82     + new_code();
  83   83     }

Added and removed lines also have separate highlighting.

Long source lines and diffs can be wrapped directly inside the TUI.

Search and navigation

RepoTrek provides several ways to move around a repository.

File search

Search files by name and quickly jump to a result.

Code search

Search repository contents and open matching files directly.

Symbol navigation

Inside a source file, @ opens a symbol picker.

For Rust, for example, RepoTrek can identify things such as:

struct
enum
trait
impl
fn

Definition search

Pressing d searches for likely definitions of the identifier around the current cursor position.

This is currently heuristic-based rather than a full LSP implementation.

GitHub information inside the TUI

RepoTrek is gradually bringing more of the GitHub repository experience into the terminal.

It can display information for:

Code
Commits
Pull Requests
Issues
Actions
Releases

When the web interface is still useful, pressing o opens the corresponding GitHub page.

The goal isn't to eliminate the browser completely.

The goal is to make it optional during normal source exploration.

Keyboard-first

I wanted the application to remain usable almost entirely from the keyboard.

For example:

Shift+J    extend selection downward
Shift+K    extend selection upward
Shift+A    select all
Shift+C    copy

v          Vim-style selection
y          copy selection

Esc        clear selection / go back

There are also shortcuts for searching, switching branches, toggling themes, wrapping lines, and opening external GitHub pages.

Dark and Light themes

RepoTrek supports both Dark and Light themes.

The Light theme is not just an inverted Dark theme.

Syntax colors, selected lines, active lines, and diff colors are defined separately so source code remains readable in both modes.

The selected theme is persisted between sessions.

Printing source code from a TUI

One slightly unusual feature is HTML export.

RepoTrek can generate printable HTML for source files and diffs.

Exports include:

Syntax highlighting
Line numbers
Old/new diff line numbers
Added/removed line backgrounds
Print-oriented layout
A4 landscape CSS

Files are automatically written to:

exports/

with timestamped filenames.

I sometimes like reading larger pieces of source code away from the editor, so I wanted RepoTrek to treat printing as a real output format rather than an afterthought.

Built with Rust and Ratatui

RepoTrek is written in Rust and uses Ratatui for the terminal UI.

At a high level, the architecture looks roughly like this:

GitHub API
    ↓
Provider
    ↓
RepoTrek models
    ↓
Application state
    ↓
Ratatui UI

I intentionally keep GitHub-specific API structures away from most of the UI.

The idea is to make support for other Git forges possible later.

Potential future providers could include:

GitLab
Gitea
Forgejo

Cross-platform releases

RepoTrek is built for:

Linux
  x86_64
  ARM64

macOS
  Apple Silicon
  Intel

Windows
  x86_64
  ARM64

Release builds are automated with GitHub Actions.

The project is also available through crates.io:

cargo install repotrek

What's next?

RepoTrek is still a v0.x project, so there are many things I want to improve.

Some ideas include:

Better symbol analysis
LSP integration
Improved commit graphs
Better PR review navigation
More GitHub Actions information
Smarter caching
Performance improvements for very large repositories
GitLab / Gitea / Forgejo support
Better terminal capability detection
Mouse support where useful

But the main goal will stay the same:

Make exploring source code from the terminal enjoyable.

Try it

GitHub:

https://github.com/yuna-r/repotrek

crates.io:

https://crates.io/crates/repotrek

Install with Cargo:

cargo install repotrek

If you enjoy Rust, TUIs, open source, or simply reading other people's code, I'd love for you to try it.

Feedback, issues, and pull requests are welcome 🐻🦀