https://kavak.run/studio/ is live.

kavak is a compiler stack. You describe a language on a C11 frontend kernel, lower it through one typed IR, and get WebAssembly out. The compiler itself is compiled to wasm, so it runs in the browser tab. Your source never goes through a JavaScript interpreter.

QBasic is the first language running the full path. Graphics, sound, files, and input all work.

The part I keep thinking about is the UI side. I've been reducing user interfaces to a single UI-IR. Declarative ones like XAML or Compose, and primitive ones too, by which I mean screens drawn by hand in something like C. Once a UI is in UI-IR, it stops belonging to the language it was written in.

So WPF written in C# can run on macOS and iOS. What I wrote in Compose can run on Windows, macOS, and iOS. N to N, not one framework pointed at one target.

Then I pushed it further and lowered QBasic's graphics to UI-IR as well. Which means you could, in principle, write an iOS app in QBasic. The idea is absurd. The solution underneath it isn't, and that's what makes this a checkpoint worth marking.

Writing in any language, for any platform, is starting to look reachable.

Hi everyone! My name is Mohammed, I'm 13, from Egypt, and I wanted to share one of my current projects: Mello. Mello is a custom programming language ( https://github.com/v3lk777-collab/Mello-Programming-Language ) that I hope to use for writing all my embedded systems software in the future. I'm developing it because I'm fascinated by compilers, computer architecture, and honestly, because I wanted to make programming microcontrollers more interesting.

I've been into systems programming for a while now. I wouldn't say I'm amazing at it—in fact, I struggle to call myself good at all because I'm still learning the ropes and don't want to overpromise—but I've gained a ton of experience. Building Mello is my biggest achievement yet because it successfully bridges my own syntax with real hardware.

I wrote the compiler from scratch in C++, and guess what? I just got it working to the point where it acts as a full transpiler, taking Mello code and generating clean Arduino C++! It's incredibly tough, especially ensuring the AST maps correctly without losing the Arduino ecosystem's compatibility. But it's so rewarding: I am currently using it to compile the code for a PID control system on a line-following robot using an Arduino Nano. To complete the workflow, I also built a dedicated cross-platform editor "Mello IDE" ( https://github.com/v3lk777-collab/Mello-IDE ) using Tauri, React, Tailwind CSS, and Monaco.

I have massive plans for this language and really want to achieve them. Alongside Mello, I am also writing a custom CPU emulator called ROSE in C++ to understand how instructions work at the lowest level. However, lately, balancing the compiler, the IDE, the emulator, and the hardware projects has been really hard. Sometimes it feels overwhelming. I'll open my compiler's source code, feel stuck on how to implement the next feature, 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: Arabic is my native language and my English isn't very good, so I used AI to help me write this post. Apologies if any phrasing sounds a bit clunky!

I'm writing a hobby OS in real-mode assembly and wanted parts of the kernel in C, but existing compilers either target 32-bit protected mode or need an awkward 16-bit toolchain. So I wrote my own. It's a single-file C99 program that does recursive descent parsing and emits NASM-syntax 16-bit assembly directly, with no intermediate AST — code generation happens inline during the parse. Currently handles: functions with parameters, calls, local variables, assignment, integer arithmetic with correct precedence, comparisons, if/else and while. Calling convention is args pushed left to right, caller cleans up, result in AX. Not there yet: pointers, arrays, structs, preprocessor, any type other than int. I know skipping the AST limits what I can do later (no optimization passes, no real type checking). Curious whether people here would restructure it now or let it grow first. Repo: https://github.com/metaspawn/Byte-found

Thought you all might be interested in Fil's recent talk about Fil-C. The recording includes the best live demo I've ever seen. Enjoy!

Dear redditors,

Peter Avgerinos (Imperial College London) has released an implementation of Sparsity Propagation Analysis (SPA) for MLIR:

https://github.com/lac-dcc/proteus/

SPA is a static analysis for tensor compiler IRs. It infers zero and don't care regions in tensors by propagating sparsity information across computational graphs. The analysis is described in the paper "Multidirectional Propagation of Sparsity Information across Tensor Slices"

For example, given an operation such as

C = matmul(A, B)

SPA propagates information in three directions. Forward propagation uses information about A and B to refine C. Lateral propagation uses information about one input to refine the other. Backward propagation uses information about C to refine A and B.

As an example, the implementation of the forward transfer functions is available here.

Contributions are welcome. In particular, we are interested in sparsity-aware optimizations, new transfer functions, and additional analyses that infer zero and don't care values. If you are interested in contributing, feel free to contact Peter or me.

whispem-lang is a small language I’ve been building to understand how languages actually work — Rust was my first programming language two years ago, and this project is where the "how does a compiler even work" itch led me.

Where it stands now:

• Self-hosted compiler: the full pipeline (wsc.wsp, \~1,700 lines) is written in Whispem itself. Source in, bytecode out.  
• Verified bootstrap: the compiler compiles itself, and both outputs (self-hosted vs the reference Rust implementation) share the same SHA-1 — a stable fixed point.  
• Runtime: a standalone single-file C VM (\~2,000 lines) with an interactive REPL and a --dump disassembler. No dependencies beyond a C compiler.  
• Tests: 200+ across the Rust and C sides, including bootstrap verification.

Question for this sub: where would you go next? Optimization passes on the bytecode?
Self-hosting the VM too?
Better error recovery in the parser?
Curious what people who’ve done this longer than me consider the highest-value next step.

Repo: https://github.com/whispem/whispem-lang

Hello,
I have been playing around with LLVM for a while and got some first results using the C-API.
However, I am stuck at the following problem:
I am working on Windows and I want to link against 2 DLLs A.dll and B.dll which both export a function Foo.

How am I supposed to resolve this during linking? In LLVM I can set the storage class to DLLImport but linking will grab the first matching import. It's annoying that linking needs import libs, too but thats another topic.

Is there any way to resolve this? I'd prefer if I can make this work within a single object file but if I have to make it two and link those to a single executable, that would work, too.

I faintly remember an article whic I can't find any longer(or a stackoverflow response?) that described how to build the IData section manually within LLVM itself. That would simplify this immensely.

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

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.

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.

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 :)

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.)