DEV Community: Ignacio Peña

Tempo v1.0.0: We Built a Systems Language That Actually Replaces C

Ignacio Peña — Sat, 21 Jun 2025 22:16:38 +0000

TL;DR

After building a real-time OS and hitting the limitations of C, we created Tempo - a systems programming language with memory safety, deterministic execution, and zero overhead. It's not a toy - we're using it to build AtomicOS.

The Problem

Every few months, someone announces a "C killer" that turns out to be either:
Too high-level for real systems programming
Too complex (looking at you, Rust)
Missing critical features like inline assembly
Just... not actually replacing C
We were building AtomicOS, a deterministic real-time security OS, and kept running into C's fundamental issues:
Memory unsafety is baked into the language
Undefined behavior everywhere
No way to guarantee execution time
The preprocessor is a footgun factory

Enter Tempo v1.0.0

Instead of complaining, we built the language we needed. Here's what makes Tempo different:

1. Structs That Actually Work for Systems Programming

struct DMADescriptor @packed @align(16) { buffer: raw_ptr<int8>, size: int32, flags: int32, next: ptr<DMADescriptor> }
Real memory layout control. No hidden padding. No surprises.

2. A Pointer System That Makes Sense

// Safe by default - bounds checked at compile time function process_buffer(data: ptr<int8, 256>) { for i in 0..256 { data[i] = transform(data[i]); // Can't overflow! } } // Explicit unsafe when you need it function mmio_read(addr: int32) -> int32 { let p: raw_ptr<int32> = addr as raw_ptr<int32>; return *p; }

3. Inline Assembly as a First-Class Feature

`@interrupt
function timer_handler() {
asm volatile("push eax");
asm volatile("push ebx");

tick_count = tick_count + 1;

// Send EOI to PIC
outb(0x20, 0x20);

asm volatile("pop ebx");
asm volatile("pop eax");
asm volatile("iret");

}`
No more writing separate assembly files and hoping your calling conventions match!

4. Deterministic by Design

Every loop must be bounded. Every operation has known timing:
function process_packets(packets: ptr<Packet, 64>) @wcet(6400) { for i in 0..64 @wcet(100) { if packets[i].valid { handle_packet(&packets[i]); } } }
The compiler proves this function completes in 6400 cycles or less.

Real-World Usage

This isn't theoretical. We're building an entire OS with Tempo:
Boot loader ✅
Interrupt handlers ✅
Memory management ✅
Process scheduler ✅
Device drivers ✅
Network stack 🚧
Check out our kernel written entirely in Tempo: kernel_in_tempo.tempo

Performance

Tempo compiles to the same assembly you'd write by hand:
function add(a: int32, b: int32) -> int32 { return a + b; }
Compiles to:
add: mov eax, [esp+4] add eax, [esp+8] ret
No runtime. No hidden allocations. No surprises.
Getting Started

git clone https://github.com/ipenas-cl/AtomicOS.git
cd AtomicOS
make build/tempo_compiler
# Write your first Tempo program
echo 'function main() -> int32 { return 42; }' > hello.tempo
./build/tempo_compiler hello.tempo hello.s

The Future

Tempo v1.0.0 is just the beginning. We're working on:
Generic types (without the complexity)
Async/await for interrupt-driven I/O
Formal verification integration
ARM and RISC-V backends

Join Us!

We need contributors! Whether you're interested in:
Compiler development
Language design

Systems programming
Documentation
Building cool stuff with Tempo
There's a place for you in the project.
🌐 Website: https://ipenas-cl.github.io/AtomicOS/tempo/
💻 GitHub: https://github.com/ipenas-cl/AtomicOS
💬 Discussions: https://github.com/ipenas-cl/AtomicOS/discussions
Let's build the future of systems programming together!

tempo #systemsprogramming #memorysafety #rustlang #clang #opensource

Building a Security-First OS from Scratch: AtomicOS Journey

Ignacio Peña — Fri, 20 Jun 2025 23:26:52 +0000

Why Another Operating System?

Most hobby OS projects implement "security" with simple XOR operations. I wanted to prove we could do better - implementing real cryptographic primitives and hardware-enforced security from day one.

Meet AtomicOS: a security-first operating system that actually implements AES-128 encryption, SHA-256 hashing, and introduces a deterministic programming language called Tempo.

The Philosophy: Security > Stability > Performance

In Spanish, we say: "Seguridad primero, luego estabilidad y luego performance"

This principle guided every design decision. While most OS projects optimize for speed, AtomicOS deliberately sacrifices performance for security. Here's why that matters.

Key Technical Achievements

1. Real Cryptography (Not XOR!)

// What most hobby OS do:
void "encrypt"(uint8_t* data, uint8_t key) {
    for(int i = 0; i < len; i++) {
        data[i] ^= key;  // This is NOT encryption!
    }
}

// What AtomicOS does:
void aes128_encrypt(const uint8_t* plaintext, const uint8_t* key, uint8_t* ciphertext) {
    // Real AES with:
    // - S-boxes (256-byte substitution table)
    // - MixColumns transformation
    // - Key expansion with round constants
    // - 10 rounds of processing
}

The implementation includes the full AES S-box, proper key scheduling, and all the transformations required by the standard.

2. Memory Management Unit (MMU)

AtomicOS implements a complete MMU with:

2-level paging (Page Directory + Page Tables)
4KB page size
Hardware-enforced protection
Virtual memory mapping

// Memory layout
0x00000000 - 0x003FFFFF : Kernel Space (4MB)
0x00400000 - 0xBFFFFFFF : User Space
0xC0000000 - 0xFFFFFFFF : Kernel Mirror (Higher Half)

3. Tempo: A Deterministic Language

The most unique aspect is Tempo, a programming language where every function has a guaranteed Worst-Case Execution Time (WCET).

function calculate(x: int32, y: int32): int32 wcet 30 {
    let result = x * 2 + y;
    if result > 100 {
        return 100;
    }
    return result;
}

The compiler analyzes the code and verifies it will execute within 30 CPU cycles. If it can't guarantee this, compilation fails.

Building the Kernel

The kernel evolution went through several versions:

v0.1-0.2: Performance-focused (failed security tests)
v0.3: Complete rewrite with security first
v0.4: Added MMU for hardware protection

Here's the boot sequence:

; Multiboot header for GRUB
section .multiboot
    dd 0x1BADB002              ; Magic number
    dd 0x00000000              ; Flags
    dd 0xE4524FFE              ; Checksum

; Entry point
section .text
global _start
_start:
    cli                        ; Disable interrupts
    mov esp, stack_top         ; Set up stack
    call kernel_main           ; Jump to C code
    hlt                       ; Halt if kernel returns

Security Features Implemented

Stack Protection

Every function uses stack canaries to detect buffer overflows:

void function() {
    __asm__ volatile("" ::: "memory");  // Memory barrier
    // Function code
    if (canary != expected) {
        // Stack smashing detected!
        panic();
    }
}

Memory Safety

Bounds checking on all operations
Guard pages before and after allocations
Secure wiping (3-pass with different patterns)
W^X enforcement (memory is either writable OR executable, never both)

Access Control

Every operation has a security context:

typedef struct {
    uint32_t uid;           // User ID
    uint32_t gid;           // Group ID
    uint32_t capabilities;  // Capability bits
    uint32_t ring_level;    // 0=kernel, 3=user
} security_context_t;

Testing the OS

You can run AtomicOS yourself:

# Clone the repository
git clone https://github.com/ipenas-cl/AtomicOs.git
cd AtomicOs

# Build AtomicOS v0.4 with MMU
make -f Makefile.v4

# Run in QEMU
./run_mmu.sh

Lessons Learned

Security is expensive - Every security check adds cycles
Perfect is the enemy of good - Start with basics, iterate
Hardware is your friend - MMU provides real protection
Honesty matters - Don't claim "military-grade" without proof

What's Next?

[ ] Ring 0/3 privilege separation
[ ] Tempo standard library
[ ] Network stack (with security first!)
[ ] File system (with encryption)

Try It Yourself

Conclusion

AtomicOS proves that hobby OS projects can implement real security features. It's not production-ready, but it's honest about what it is: an educational project that doesn't cut corners on security.

Remember: "No exploits, no crashes, no lies."

Have questions about OS development or security? Drop a comment below or reach out on GitHub!