DEV Community: BMJ

ForgeZero Now Supports musl Cross-Compilation and Objective-C on Linux

BMJ — Sat, 06 Jun 2026 08:55:36 +0000

🚀 ForgeZero Now Supports musl Cross-Compilation and Objective-C on Linux

I've been spending the last few weeks improving ForgeZero, adding support for more toolchains and making cross-platform development a little easier.

The latest update introduces two features that I wanted for quite some time:

✅ musl cross-compilation powered by the Zig toolchain
✅ Objective-C support on Linux with automatic compiler and linker selection

The best part? No additional configuration is required.

Just write your code and let ForgeZero handle the rest.

Static musl Builds

ForgeZero can now generate fully static musl binaries, making cross-compilation almost effortless.

fz -cc main.c -musl=riscv64 -toolchain zig

The resulting binary:

main: ELF 64-bit LSB executable, UCB RISC-V, RVC, double-float ABI, version 1 (SYSV), statically linked, with debug_info, not stripped

Static binaries are incredibly useful when building:

🐳 Minimal Docker images (scratch)
📦 Portable standalone executables
🔌 Embedded & IoT applications
🖥️ Systems without glibc
🌍 Cross-platform deployment pipelines

Using Zig as the backend compiler makes targeting different architectures surprisingly simple while keeping the ForgeZero interface exactly the same.

Objective-C on Linux

This is probably the feature I'm most excited about.

ForgeZero now automatically detects .m Objective-C source files and switches to the correct compilation pipeline without requiring any flags.

fz -cc main.m

Verbose output:

Objective-C detected!
Bypassing Zig linker to use Clang with -lobjc

Running:
clang main.o -o main -lobjc -Wl,--build-id=none

Built: main

No custom scripts.

No Makefiles.

No manually remembering linker flags.

ForgeZero simply detects the language and invokes the correct backend automatically.

Why Objective-C?

Most developers associate Objective-C exclusively with macOS and Apple's ecosystem.

However, GNU Objective-C works perfectly fine on Linux through Clang and libobjc.

Supporting it means ForgeZero can now build another systems programming language using exactly the same interface as C or Assembly:

fz -cc hello.c
fz -cc hello.m
fz -asm boot.asm

The command stays the same—the build pipeline adapts automatically.

Where ForgeZero is Going

ForgeZero originally started as a tiny utility to avoid typing endless compiler and linker commands.

Over time, it has evolved into a unified build frontend capable of orchestrating multiple toolchains while automatically selecting the right backend for the current source language.

The philosophy remains simple:

Write code, run one command, and let the build system figure out the details.

There's still a lot of work ahead, but I'm happy with the direction the project is taking.

Links

⭐ GitHub & Documentation:
https://github.com/forgezero-cli/forgezero

👤 Author:
https://github.com/alexvoste

Feedback, ideas, and contributions are always welcome.

Gloria JIT v4.4.0 — Bare-Metal Control, Memory Primitives, and Structured Flow

BMJ — Mon, 01 Jun 2026 22:23:30 +0000

What is Gloria JIT?

Gloria JIT is a low-level programming language and compiler that is part of the ForgeZero ecosystem. It is written in Go and compiles source code directly to x86-64 machine code — no LLVM, no GCC, no Clang in the middle.

The goal is straightforward: give the programmer direct, unmediated control over the machine. No intermediate representation handed off to a third-party backend. No optimizer making decisions you didn't ask for. The compiler emits raw bytes, and those bytes run.

This makes Gloria JIT an interesting project for anyone curious about how compilers actually work, or for developers who want to explore bare-metal programming without the abstraction layers that most toolchains introduce.

v4.4.0 expands the language significantly, adding structured control flow, direct memory and I/O access, and a bare-metal output path for VGA framebuffer writing.

`while` Loops — Structured Control Flow

Before this release, repeated execution required manual branching. v4.4.0 adds proper while loops.

A loop runs as long as its condition is non-zero. Inside the loop body you can use standard assignment and mutation operators (=, +=, -=), and built-in calls are permitted as well. This is a meaningful step toward the kind of control flow you'd expect from a general-purpose language.

Memory Primitives — `peek` and `poke`

Two new built-in functions expose direct memory access:

peek(address) — reads a 16-bit value from the given address
poke(address, value) — writes a 16-bit value to the given address

Both accept either immediate values or runtime variables as arguments.

This is the kind of primitive that exists in very few high-level languages, but is essential for bare-metal work — writing to hardware registers, inspecting memory-mapped I/O, or building your own allocator from scratch. Handle with care.

x86-64 Port I/O

For environments that use port-mapped I/O (common in older PC hardware and embedded x86 systems), two new built-ins are available:

in8(port) — reads a single byte from the given I/O port (zero-extended)
out8(port, value) — writes a byte to the given I/O port

This enables direct hardware interaction at a level that most programming languages simply do not expose.

VGA Framebuffer Output

print(string) now supports a bare-metal execution path that writes directly to the VGA text buffer at memory address 0xB8000.

For context: on x86 PCs, this address is where text-mode video memory lives. Writing bytes there places characters directly on screen — no operating system, no drivers, no system calls involved. This is how early PC software (and modern bootloaders) produce output.

Details of the implementation:

Default text color is green (0x0A)
Register R15 is reserved as a cursor offset and is preserved across calls
Escape sequences \n and \t are resolved at compile time into the appropriate control characters

To support testing without real hardware, two utilities are included: patchVGA() swaps the real framebuffer address for a heap-allocated buffer, and dumpVGA() renders that buffer to stdout via a direct syscall, with zero heap allocations.

Register Constants

To reduce ambiguity in the backend IR and make generated code easier to reason about, named constants have been introduced for all general-purpose x86-64 registers:

regRAX(0), regRCX(1), regRDX(2), regRBX(3),
regRSP(4), regRBP(5), regRSI(6), regRDI(7),
regR8(8) ... regR15(15)

Internal Changes

A few backend improvements shipped alongside the language features:

emitLowLevelPrint now accepts a kernelMode flag to switch between syscall-based output and direct VGA writes
emitPushReg and emitPopReg now cover the full register set including R8–R15
New operations: emitMovMemToReg64, emitMovRegToMem64
parseStringLiteral handles escape sequences at compile time rather than at runtime
emitBareMetalPrint introduced for the VGA output path

Where This Is Heading

With v4.4.0, Gloria JIT operates in two modes simultaneously: as a userspace compiler with kernel-aware syscall output, and as a bare-metal code generator capable of running without an operating system underneath it.

The next focus areas are optimization passes and IR stability. If you're interested in how compilers work from the ground up — or in low-level x86 programming without giving up a proper language — this is worth following.

Gloria JIT is part of the ForgeZero project. Follow along on dev.to/alexvoste.

ForgeZero 4.1 vs GNU Make: Up to 4.5x Faster Build Performance

BMJ — Tue, 26 May 2026 13:37:57 +0000

ForgeZero 4.1 vs GNU Make: Up to 4.5x Faster Build Performance

I've been working on ForgeZero, a modern build system designed to replace traditional make with a faster, zero-config approach.

With the release of ForgeZero 4.1, I benchmarked it against GNU Make on multiple machines to answer one simple question:

Can a modern build system still significantly outperform make in 2025?

Turns out: yes.

Benchmark setup

GNU Make

make -j4

ForgeZero

./fzt -dir . -out fz_out

Measurement tool

Benchmarks were run using hyperfine:

hyperfine './fzt -dir . -out fz_out' 'make -j4'

Results

Platform	ForgeZero	GNU Make	Speedup
Ryzen 9 7950X3D (KVM, 1 vCPU)	~80–84 ms	~350–364 ms	4.1x–4.5x
Intel Core i5-10310U	82.2 ms	291.1 ms	3.54x
AMD FX-8370E (AM3+)	111.0 ms	238.5 ms	2.15x

Across very different CPUs and environments, ForgeZero consistently outperformed GNU Make.

Example benchmark output

Ryzen 9 7950X3D

Benchmark 1: ./fzt -dir . -out fz_out
Time (mean ± σ): 84.5 ms ± 7.6 ms

Benchmark 2: make -j4
Time (mean ± σ): 350.4 ms ± 16.4 ms

Summary:
4.14x faster than make -j4

Intel i5-10310U

Benchmark 1: ./fzt -dir . -out fz_out
Time (mean ± σ): 82.2 ms ± 4.2 ms

Benchmark 2: make -j4
Time (mean ± σ): 291.1 ms ± 11.2 ms

Summary:
3.54x faster than make -j4

AMD FX-8370E

Benchmark 1: ./fzt -dir . -out fz_out
Time (mean ± σ): 111.0 ms ± 17.9 ms

Benchmark 2: make -j4
Time (mean ± σ): 238.5 ms ± 24.4 ms

Summary:
2.15x faster than make -j4

Why is ForgeZero faster?

1. No shell overhead

GNU Make spends a surprising amount of time spawning shell processes (fork/exec) for build commands.

ForgeZero executes the build pipeline directly.

No unnecessary shell orchestration.

2. Lightweight dependency graph

make still carries decades of legacy behavior:

Makefile parsing
implicit rules
pattern matching
recursive variable expansion

ForgeZero builds a direct dependency graph and updates only what actually changed.

3. Better task scheduling

Instead of the classic make -j job model, ForgeZero uses a lightweight internal scheduler with lower synchronization overhead.

4. Zero-config design

No giant Makefiles.

No boilerplate.

ForgeZero analyzes project structure automatically and starts building immediately.

Why this matters

make was introduced in 1976.

Almost 50 years later, many developers still accept build-system latency as unavoidable.

These benchmarks suggest otherwise.

If your team runs hundreds of builds per day—locally and in CI—even saving 100–250 ms per build adds up quickly.

ForgeZero 4.1 is available

GitHub:

https://github.com/forgezero-cli/forgezero

I'd love feedback from developers still using make, ninja, or other build systems.

Zero Heap Allocations at 1.18 GB/s: Deep Dive into ForgeZero 4.0.x

BMJ — Mon, 25 May 2026 15:14:42 +0000

What happens when you migrate a system tool from pure Node.js to Go, strip out the standard GC-heavy paths, and force a file system engine to hit 0 allocs/op?

You get ForgeZero (fz) — an open-source bare-metal system software builder created by @AlexVoste. Designed to eliminate bloated Makefiles for low-level developers, it orchestrates NASM, GAS, FASM, GCC, and Clang concurrently under a single unified .fz.yaml configuration.

With the recent launch of version 4.0 and its subsequent 4.0.1 patch, the project underwent a radical low-level optimization sprint targeting Go's runtime overhead.

Here's a technical breakdown of how it achieves near-native bare-metal execution speeds.

⚡ The Benchmark Reality Check

Running on an Arch Linux testbed (Intel i5-10310U), the updated engine delivers striking performance metrics:

Metric	Result
Data throughput	~1.18 GB/s steady state
File hashing (100 MB payload)	~78–84 ms
Memory footprint	0 allocs/op across all hot-path runs

goos: linux
goarch: amd64
BenchmarkHadesEngine/Process100MB-8   14   78411200 ns/op   0 B/op   0 allocs/op

By completely avoiding heap allocations on critical execution paths, the application bypasses Go's Garbage Collector entirely — achieving deterministic latency similar to C or Rust.

🛠️ The Architecture: Under the Hood of HADES

To pull off 0 allocs/op while scanning deeply nested directory structures and executing multiple sub-processes, the compiler architecture leans on three internal layers.

1. The HADES Engine & Memory Re-use

The file system sub-engine (fs, seal, and the linker/assembler modules) was fully overhauled. Instead of spawning new byte slices or strings during recursive scans, ForgeZero:

Pre-allocates localized memory arenas and sliding ring buffers
Handles path strings via direct string-to-[]byte headers (unsafe.Pointer), dodging the typical heap allocation penalty associated with dynamic string manipulation in Go

2. Multi-Engine Concurrency & Automated Fallbacks

ForgeZero dynamically parallelizes multi-file assembly:

Single file: matches input files directly to object targets (fz -asm boot.asm)
Directory: parses whole structures recursively (fz -dir ./src)

The engine also implements an aggressive link-level degradation system:

Try gcc compilation
Fallback to gcc -no-pie if position-independent execution fails
Degrade cleanly to a bare ld link for completely naked environments

3. Explicit Mode Switches

For strict bare-metal control, devs can override automated link behaviors via targeted CLI flags:

-mode c — explicitly lock execution strictly through GCC
-mode raw — bypass safety overrides and link unmanaged binaries directly with raw ld

🚀 What's New in Patch 4.0.1?

While 4.0 laid the groundwork for memory optimization, the 4.0.1 hotfix secures edge cases in bare-metal pipeline execution.

Silent-by-Default Pipeline
Hides external noise from standard tooling (like nasm or gcc), displaying a clean single-line state block: Built: program.out. Errors are trapped and viewable in full via the -verbose flag.

Collision Resolution
Fixes namespace collisions on identical file names using distinct low-level syntax extensions — e.g., main.asm and main.s now map correctly to independent main_asm.o and main_s.o components without cross-contamination.

Garbage Cleanup
Refined -clean runtime structures to ensure all cross-compilation objects (.fz_objs temporary workspaces) are recursively pruned using zero-allocation OS system calls.

💻 Getting Started

For system engineers moving away from manually typed, multi-stage assembly toolchains:

# Pull the latest bare-metal builder package directly via Go
go install github.com/forgezero-cli/forgezero@latest

Make sure your underlying assembly tools (nasm, fasm, ld, etc.) are globally mapped within your system $PATH.

Check out the fully-tested source tree, architecture specs, and documentation over at the official ForgeZero GitHub Repository.

DEV Community: BMJ

ForgeZero Now Supports musl Cross-Compilation and Objective-C on Linux

🚀 ForgeZero Now Supports musl Cross-Compilation and Objective-C on Linux

Static musl Builds

Objective-C on Linux

Why Objective-C?

Where ForgeZero is Going

Links

Gloria JIT v4.4.0 — Bare-Metal Control, Memory Primitives, and Structured Flow

What is Gloria JIT?

while Loops — Structured Control Flow

Memory Primitives — peek and poke

x86-64 Port I/O

VGA Framebuffer Output

Register Constants

Internal Changes

Where This Is Heading

ForgeZero 4.1 vs GNU Make: Up to 4.5x Faster Build Performance

ForgeZero 4.1 vs GNU Make: Up to 4.5x Faster Build Performance

Benchmark setup

GNU Make

ForgeZero

Measurement tool

Results

Example benchmark output

Ryzen 9 7950X3D

Intel i5-10310U

AMD FX-8370E

Why is ForgeZero faster?

1. No shell overhead

2. Lightweight dependency graph

3. Better task scheduling

4. Zero-config design

Why this matters

ForgeZero 4.1 is available

Zero Heap Allocations at 1.18 GB/s: Deep Dive into ForgeZero 4.0.x

⚡ The Benchmark Reality Check

🛠️ The Architecture: Under the Hood of HADES

1. The HADES Engine & Memory Re-use

2. Multi-Engine Concurrency & Automated Fallbacks

3. Explicit Mode Switches

🚀 What's New in Patch 4.0.1?

💻 Getting Started

`while` Loops — Structured Control Flow

Memory Primitives — `peek` and `poke`