Hi everyone,

I'm working on a programming language that compiles a subset of C. It is called Cm1 (meaning C minus 1) and you can writing and running C codes directly on your browser at https://cp1-lang.org/cm1/editor.html in a fraction of a second.

Why is it faster to compile than Tiny C Compiler? It is because Tiny C Compiler is a true compiler creating native binaries whereas Cm1 is a bytecode interpreter allowing you to test, debug, edit code and recompile very quickly or even do hot reloading. Cm1 can be used as a scripting language for shell scripts and video games, but this just a small use case because in theory, you can run 90% of your ENTIRE video game or software C program through Cm1's bytecode interpreter and leave 10% to compiled C and reap the benefits of very fast compilation and hot reloading.

100% Cm1 codes are compilable by GCC and Clang but the reverse is not true since Cm1 is just a subset of C. Major features that are omitted are function pointers, structs/unions inside functions, nested structs/unions. This programming language is under heavy development and I want to know if this comes as interesting to some of you. I'll try to post again on this subreddit if I got to bind Raylib game library to Cm1, allowing people to write Raylib games directly on their browser (works offline).

I know that programs that are written in C compiles fast already and there's even an existing compiler that is very fast (Tiny C Compiler). However, I'm the developer of Cp1 programming language (cp1-lang.org), which is a language that "transpiles" to C, and I aim to upgrade Cp1 by targeting the Cm1 language then compile it to bytecode in one command instead of a separate step in Makefiles or build scripts. This will make Cp1 very fast to compile for debug builds.

I am trying to figure out this question and don't know the answer nor how to solve it:

Given the following program (assume int is 4 bytes):

Here's the code:

function main() return integer is
  n: integer;
  function square(v: integer) return integer is
    function double_it(u: integer) return integer is
    begin
      return __________;
    end;
  begin
    return double_it(v * v);
  end;
  function cube(v: integer) return integer is
  begin
    return v * v * v;
  end;
begin -- of main
  n := 6;
  return square(n) + cube(n);
end

Part A

Assume that in the double_it() function, the expression v * v + u replaces the underline.

Complete the missing offsets in the following code:

load RS1, __(FP)

load RT1, __(RS1)

mul RT2, RT1, RT1

load RT3, __(FP)

add RV, RT2, RT3

Part B

Assume that in the double_it() function, the expression v * v + n replaces the underline.

Complete the missing offsets in the following code:

load RS1, __(FP)

load RT1, __(RS1)

mul RT2, RT1, RT1

load RS2, __(RS1)

load RS3, __(RS2)

add RV, RT2, RT3

How do I determine the right offsets?

This is part 2 of post: https://www.reddit.com/r/Compilers/s/E5R5MQSlQe

I recently finished implementing CMOVcc, SETcc, and the first group of SSE instructions in my handwritten x86-64 assembler written in C.

Seeing objdump correctly decode the generated object file is always satisfying.

I'm still implementing more of the x86-64 ISA, so if there are instruction groups you'd like to see next, I'd be happy to hear suggestions, and feedbacks. Thanks!

Github: https://github.com/LinuxCoder13/AmmAsm

I'm building a DSL (ANTLR4-based) that compiles my own 3D-printer control code down to different firmware gcode dialects (Klipper, Marlin, RepRapFirmware [working on that]). It was a school project very early in the year and I really love 3D printers so that's the subject I chose. The compiler is machine agnostic, so adding new firmware targets is just a matter of subclassing the base visitor.

 We only learned about using ANTLR in class so I'm new to pretty much anything else. I’ve read up on some beginners books but it’s mostly been trial and error. Honestly, I feel like my grammar is being held up by duct tape and prayers and I was lucky enough to have had a great contributor help apply some fixes along the way.

To my question, I realize I have a “minus munching” problem.

 My number token is currently:

NUMBER : '-'? [0-9]+ ('.' [0-9]+)?; 

I've written up a proposed fix as an issue in my own repo: stripping the  '-'? part out of the lexer rule and instead adding a unaryMinus rule to the expression grammar with a visitor that negates the recursive result.

Here's the issue with the proposed fix: https://github.com/Disla-Novo/Dimidium_Bellerophon/issues/70#issue-4921171148

Before I implement it, is this actually the standard/correct way to handle this, or is there a better approach I'm missing or didn't research enough on? Would appreciate a sanity check from anyone, thank you.

What My Project Does

Lucen is a source-to-source compiler that parallelizes ordinary for loops you mark with two comments:

# LUCEN START
for i in range(len(rows)):
    out[i] = expensive(rows[i])
# LUCEN END

It parallelizes a loop only when it can prove the work is safe and worth it; otherwise it stays sequential. The one guarantee, no tiers, no opt-out: a parallel run is bit-identical to the same file run as plain sequential Python (floats and container order included). Delete the comments and nothing changes.

CPU-bound work routes to processes on GIL builds and to real threads on free-threaded 3.13/3.14. Optional Rust core with a pure-Python fallback, so pip install lucen always works.

Target Audience

Anyone with CPU-bound Python loops - data processing, simulation, batch transforms - who wants their cores without rewriting to multiprocessing/joblib or reasoning about locks. It's v1.1, built correctness-first: Apache-2.0, differential/property tested, TLA+ specs, signed PyPI releases.

Comparison

• vs multiprocessing/concurrent.futures: no manual pool/chunking/pickling boilerplate, plus a profitability gate that declines to parallelize when it wouldn't help.
• vs joblib/Dask: no new API and no cluster - you mark the loop you already have. It's correctness-preserving local parallelism, not distributed compute.
• vs Numba: Numba compiles numeric bodies to native code; Lucen parallelizes the loop for arbitrary Python and guarantees identical results. (Native loop-body compilation is on the roadmap.)

pip install lucen

https://github.com/fcmv/lucen

initially opened the Kimi K3 release, probably like everyone else on the planet, just because of the obvious headline: 2.8 trillion parameters.

After spending a few days digging through the architecture, I actually think that is the least interesting number.

The interesting question that sparked into my mind is: what happens when you scale model capacity while aggressively keeping active computation under control?

K3 activates 16 of 896 experts per token. That means the model is storing a massive amount of capacity, but only a small fraction participates in each forward pass. this actually shifts the bottleneck

The million-token context is also interesting because it changes the economics. Long context is usually presented as a capability problem, but at this scale it is really a memory and serving problem.

The question I keep coming back to over and over: are frontier models moving from being primarily "large neural networks" toward being "large distributed systems with neural networks inside"?

Curious what people working on MoE systems think. Is expert routing/load balancing becoming the real scaling bottleneck?

(I wrote a longer analysis with some simulations, but I'm mostly interested in the discussion here.)

https://open.substack.com/pub/softwarefrontier/p/kimi-k3-28-trillion-parameters-four?r=3c7w5a&utm_medium=ios

Hi everyone! My name is Samir, I'm 16, from Russia, and I wanted to share one of my current projects: Veo (https://github.com/SamirShef/veolang). Veo is a systems programming language that I hope to use for writing my own software in the future. I'm developing it because I'm fascinated by compilers, and honestly, because I just needed something to occupy my time.

I've been into compiler dev for over a year now. I wouldn't say I'm amazing at it—in fact, I struggle to call myself good at all because I'm afraid of overpromising—but I've gained a ton of experience. Over the past year, I've built about 15 programming languages, and Veo is the best one yet because it's the only one to reach the self-hosting phase.

I'm currently rewriting the compiler in Veo itself, and guess what? I just got the first binary working (only global variables for now, but still!). It's incredibly tough because there are no generic-based collections yet—all collections are polymorphic. But it's so rewarding: it took me 2 months to write the first version of the compiler in C++ (stage0), and that compiler successfully compiled the second version (stage1), which I wrote in just two weeks using Veo itself. Then, stage1 successfully compiled some test Veo code.

I have massive plans for this language and really want to achieve them. However, lately, it's been really hard to make progress. I have zero motivation. Maybe I'm burnt out, I don't know. It’s frustrating because I'll write just a couple of lines of code in stage1, immediately feel like I can't go on, and just shut down my PC.

This project isn't revolutionary or anything. Sharing it here means I'm just looking for a bit of recognition and some objective, constructive criticism.

Note: This post was translated into English using AI because my English isn't fluent enough to write this freely. Apologies if any phrasing sounds a bit clunky!

For decades, programmers have solved new problems by creating abstractions in libraries before languages officially supported them.

Some of these patterns eventually became language features. inline is one example. _Generic is another.

But many important abstractions still live only as library conventions.

Large C projects are good examples. GObject/GTK built their own object model. Linux VFS has its own object-oriented design. Many projects repeatedly create similar patterns in different ways.

This makes me wonder:

Is there a point where a commonly repeated library pattern should become a language feature?

What signals that transition?

• widespread adoption?
• compiler optimization opportunities?
• better expression of programmer intent?

Or should some abstractions always remain libraries?

Curious how people think about this boundary.

I ran into a fun little ABI bug while working on my programming language, Dray.

The exact same generated C code printed:

Linux:
nums[0] = 10
...

Apple Silicon:
nums[0] = 0
...

I wrote up the debugging process, the ABI differences, and how I ended up changing Dray's FFI syntax to support C variadics here:

https://bichanna.github.io/posts/same-code-printed-diffly/

I'd be interested to hear if anyone else has run into similar ABI related compiler bugs or FFI gotchas :)

offering my 12 years work in a form of a header only C++ template metaprogramming library, under MIT licence. Enjoy!

fell free to ask about it...

HAPI does not optimize it lets the compiler optimize, and it will reflect the behavior of the components, if your components are vtable free, so will be the result, if they are zero-cost so wil be the result. Hapi does not impose its just transforms and is transparent.

Link to the project: https://github.com/romainducrocq/wacc-selfhosted

Nora Sandler's Writing a C Compiler is a beloved book here and a hands-on guide on writing a compiler for a large subset of C. This subset, called Not-Quite-C, covers all the operators, if statements, loops, switch cases, variables and functions, storage classes, multiple integers types, double floating points, pointers, fixed sized arrays, structures and unions, as well as a handful of optimization passes. And... that is enough of the C language to write a selfhosted compiler, so that's exactly what I did! 

Here is a full selfhosted implementation of Writing a C Compiler written in Not-Quite-C. The compiler can first be bootstrapped with gcc/clang (it is a valid subset of C17 after all), nqcc2 (the reference compiler), wheelcc (my previous project) or any other complete implementation (like your own), and then rebuild itself (multiple times!) on Linux, MacOS and FreeBSD: in result, the selfhosted compiler passes all 20 chapters of the test suite with extra credits. If you finished this project yourself, this is a great way to test that your implementation can compile a large program using every language feature in WaCC. Basically, being able to rebuild this compiler with your own is the final boss for this book! 

Enjoy! 

(This project was entirely handwritten by me, without the use of LLMs.) 

I have recently making my own programming language. The language is compiled to LLVM IR.

It's written completetly with C, and it's on a very initial stage.

Anything, from a contribution to an idea, suggestion ir anything is really helpful to the project.

Here's the link: https://github.com/Pacsfury/Gravel-Launcher

Please follow AI-POLICY.md and be respectful.

I implemented it in Zig. I really learned a lot from this book and this project so I can highly recommend it. My code design is different from the book because I tried to apply data oriented design I learned from Zig compiler itself as much as I could.

AI disclaimer: not a single line of code was written with AI but it was used to help me debug issues.

Hi everyone,

I’ve spent the last several months building Aziky, a self-contained compiler toolchain written entirely in Rust from the ground up. The core goal of the project was to bypass generic optimization frameworks like LLVM and explore how far a custom, single-pass backend could be pushed by shifting the optimization burden directly into front-end semantics.

It compiles .azk source files straight down to a custom MachineLIR and maps primitives directly to hardware registers, bypassing standard intermediate layers.

Architectural Highlights:

• Native Binary Generation (src/object): The compiler constructs binary headers, section tables, and relocation frames completely natively. It outputs fully formed ELF64, Mach-O64, and PE32+/COFF formats without invoking external linkers or assemblers.
• Zero-Alias Invariants: Instead of relying on hundreds of heavy middle-end analysis passes to guess if pointers overlap, Aziky enforces explicit, deterministic parallel-loop and ownership invariants at the type level. Because the compiler can guarantee non-aliasing at the frontend, the backend emitter can immediately output aggressive, optimized machine instruction sequences.
• Zero External Dependencies: The entire compiler dependency graph has zero third-party crates, ensuring entirely offline, reproducible, and rapid compilation.

Performance Snapshot: Running standard compute-heavy microbenchmarks on an Intel Core i5-7200U (median of 100 runs, pinned to CPU 1) against aggressively optimized production builds of Rust 1.88 (-C opt-level=3 -C target-cpu=native -C lto=fat) and Clang 22 (-O3 -march=native -flto), the upfront aliasing model allows us to hit a geometric mean execution speed advantage of ~1.87x over optimized Rust and ~1.27x over optimized C.

It’s currently in alpha—Linux x86-64 is the primary native target, with Windows and macOS execution partially supported (AArch64 is on the roadmap). I’ve also bundled an installable VS Code extension in the repo for real-time diagnostics and syntax formatting.

I'd love to get your feedback on the MachineLIR structure, the single-pass register allocator layout, or the native object emission pipeline.

Repository:https://github.com/aziky-lang/aziky

(Blog post, sort of)

This is JIT for interpreted, dynamically typed languages, and I have tracing-JIT in mind since the only products I can test are Python/PyPy and Lua/LuaJIT.

This is not really about products like JS which have had $millions in development - I'm looking for an approach I can use for my own small-scale efforts!

There seems to a be distinct lack of data apart from the usual micro-benchmarks where LuaJIT especially can often manage native code performance. I want to know how much difference it makes to real applications.

My benchmarks I only have two vaguely realistic tests, and only one of those runs on both PyPy and Lua:

                        PyPy          LuaJIT
JPEG decoder test       10x           --
Lexer benchmark         10x           10-20x

I've kept the figures rough, but they are representative. Here the JIT product runs about 10 or more times faster than the regular non-JIT one.

That sounds great, however there are two problems:

• In both cases, it is still some way off native code speed, by a magnitude or so
• My own interpreter already has a performance which pretty much matches both of those JIT products for these two tests.

(It manages that by being a little less dynamic and having some features conducive to fast interpretation. Plus a lot of experience.)

I'd like my interpreter to get closer to native code, and I want to do it without using static type annotations. I tried that earlier this year, and it looked promising, but I just didn't like it - too much was sacrificed.

I want my dynamic language to stay dynamic, informal, uncluttered and spontaneous, and not turn into my systems language, which is almost what happened.

I have some ideas in mind, but I wanted to be surer that trying to do tracing-JIT, which I understand very little anyway, probably isn't going to help.

Tracing-JIT gives decent results for Python/Lua in my examples because the non-JIT implementations were so slow to start with!

What is JIT I call an interpreter 'pure' when it doesn't use any dedicated native code to run a specific program; it interprets a byte-code instruction at a time, and only executes native code already within the interpreter.

If it has to generate specific native code sequences depending on what is in the program, then it starts to be JIT-accelerated.

That is my view anyway. I've kept my interpreters pure so far and tried to keep them efficient.

Hi everyone,

I'm starting to learn the LLVM C++ API, and while I understand the basics of C++, I'm finding it a bit overwhelming to figure out how to actually write programs using LLVM.

I'm looking for resources that focus on practical examples rather than just explaining the architecture. I'd like to learn things like:

How to generate LLVM IR using the C++ API.

How to create modules, functions, basic blocks, and instructions.

How to work with different integer types, including larger integer types.

How to debug LLVM API code effectively.

Small projects or exercises to practice with.

I've already gone through the Kaleidoscope tutorial, but I'm curious if there are other tutorials, books, blogs, YouTube channels, or GitHub repositories that you found helpful when learning the LLVM API.

I'd really appreciate any recommendations or advice. Thanks!

AmmAsm is an open-source, handwritten x86-64 assembler written in C from scratch.

Hello, my name is Ammar, and I'm 15 y. o. About a year ago I started writing AmmAsm, a handwritten x86-64 assembler in C as a way to learn how machine code, ELF, and linking actually work.

Today it can generate Linux x86-64 executables, PIE binaries, and ELF relocatable object files that can be linked with "ld" or "gcc". Along the way I implemented a lexer, parser, expression evaluator, x86-64 instruction encoder, ELF writer, relocations, and symbol resolution. It syntax is almost same with Intel, as it has major difference: using [b=, i=, s=, d=] addressing instead of Nasm's [base + index * scale + disp]

it is bootstraped about 0.257% :)

The latest version(2.2.0) also includes a macro preprocessor.

I'd really appreciate any feedback on the project, code, or documentation. Thanks!

repo: https://github.com/LinuxCoder13/AmmAsm.git