I am working on my own compiled programming language, and I figured that a decent test suite would save many headaches down the line (especially as my current code is in desperate need of refactoring). The problem is, I am not sure how to test a compiler without just mindlessly writing a bunch of end-to-end tests as that would be slow and unlikely to catch obscure bugs

While implementing the OO part of my language (AET), I ran into a performance problem: OO method calls have overhead. So I started looking into devirtualization.

At first, I treated it as a compiler problem: how can the compiler determine that a method call has only one possible target?

But then I started thinking from a different angle: what if the language itself could tell the compiler that the target is unique?

This made me realize that the relationship between language semantics and compiler shouldn't be one-directional. They should influence each other during the design phase:

Language Semantics ↔ Compiler ↔ Optimization

For example, AET has:

private$ foo();
final$ foo();
final$ class A { ... };

These are language semantics that restrict inheritance and overriding. But they also provide the compiler with clear semantic guarantees: the call target is unique.

A final$ method cannot be overridden by subclasses.

A final$ class has no subclasses that could override the method.

A private$ method does not participate in overriding at all.

Different language rules, but from the compiler's perspective, they all provide the same useful fact: the call target is unique. So AET can use this semantic information to transform an OO call into a direct call to the corresponding FUNCTION_DECL in GCC's intermediate representation.

Of course, a compiler could also discover the same information through type analysis, call graph analysis, devirtualization, LTO, etc. But if these facts can be determined directly by language semantics, could it in turn make the compiler simpler?

This led me to a more general question. Essentially, it's a "who does more, who does less" problem. If language semantics provide more explicit guarantees, the compiler may need to do less inference. If the language keeps weaker semantic constraints, more work falls on compiler analysis.

So the question becomes: what should be left to language semantics, and what should be left to compiler analysis? Are there any methods or theories to guide this division of labor, to make it more scientific and reasonable?

I think this is also a boundary worth discussing between language design and compiler design. AET is my exploration of this question while actually implementing it.

Would love to hear your thoughts.

Then , rust , how to save its previous edition codes? I wonder how to rust accept its particled edition's codes on futures seamlessly . This is about the maintanence, not just about shovelling the previous codes.

It must invest the a plenty of management assets. However, the resources are restricted. So rewrite in their language is not hopefull.

And the billions lines of codes are not as seamlessely transpiled adjustly. And over, the rust's editions politics are accelerarate their own fragments.

The fragments are must become accumulates debts of the managements and mantainences.

When it comes to persist, the one-shot must cut-down the whole.

"REWRITE IN RUST" is somewhat

brave sentences, nontheless its realities. The truth unveil on real world, is not easy .

The legacy, a plenty of softwares were written by others(by other person, with other languages, so on).

It is nonsense to write software in rust wholy.

The intent of the developer is exist. This not fair , while the codes are not have memory-safety features. All codes have reasons. Tortue the codes to become memory-safety codes are not justice.

As it transpiled automatically or by-hand, the intent is might not same as origin's.

We must have to know "context" of the legacy codes.

It has its own history, innate algorithms, the intents.

We are not must to preserve the origin's intents, but, the understanding the its own scripts are also important.

Because of the developers are such as like as artists.

Their intents are might can be interpreted on many ways.

However, we must do acknowledge to precisely : why the author descripted this and what is its intents?

It is also similiar as using the ai to transpile the previous legacy codes into newer version of codes. Thats are not seamlessely to translate naturally.

Rust's codes are can be the legacy codes too. Whenever what written in, those are legacy.

Ai-derived codes, or manually handled, whichever, the codes can be legacy.

You must intend the logic or algorithm to write down the programs, nontheless the logic is not complete, and also the origin-thoughts are already exists.

We think why the ai-based automatic transpilation is might be dangerous or harmful: this is because the overall programs context is not fully understand by aritificial-intelligence. That is the much greater problems occurs.

Partial knowledge is might become to be dangerous ,

so the misleading to be misinterpretings.

And also, ai could not understand the entire codes contexts.

In addition, to understanding full program's context by ai, are much consume energy.

Such as electrical energy, and noise can occurs, this is not good to environments and vice versa to mankinds(entire employees, and companies , etc.).

It is must cause maintaneance fatigues.

Suppose to : While the all codes are transpiled to rust, it is might cause more problems.

When the rust version and edition updates to latest , the management problems are huger then before.

Hey everyone,

I wanted to share a major milestone on my hobby language project called Uranium, written from scratch in modern C++ (C++17/20).

I deliberately avoided LLVM because I wanted to learn and build the execution pipeline myself from the metal up.

Architecture Highlights:

• Lexer & Parser: Emits .urc bytecode with peephole optimization. Supports strict static typing, generic syntax, pattern matching (match/case), nested f-strings (f"Outer: {f"Inner: {x}"}"), and async/await with a cooperative task scheduler.

• Custom Native JIT: In src/native_jit_x64.cpp, I implemented a small assembler (X64Assembler) that directly emits raw x86_64 opcodes for hot loops and arithmetic routines into executable memory pages.

• Generational GC: Two-tier Mark & Sweep (HEAP_COLLECT_YOUNG vs HEAP_COLLECT_FULL) with write barriers (writeBarrier(owner, value)) tracking remembered sets, plus object pooling.

• Standard Library & Tooling: Includes raw TCP sockets, native cryptography (SHA256/Base64), embedded SQLite3, Godot engine bindings, its own build tool (omake), and a preview VS Code LSP extension.

The codebase is completely open-source. I'd really appreciate any code review or architecture critiques from other compiler authors:

https://github.com/bruhgit/Uranium-Programming-Language

What do you think of the tiered JIT / Loop Broker approach?

I've been working on a new programming language for the past few weeks, and although I've already made some design choices, I'm still questioning some of them.

So I'm curious about the opinions of people here:

• Are you more on the static typing side (C++, Java, C#, Rust...) or the dynamic typing side (Python, JavaScript...)?
• And more importantly: why?

A related question: what's your opinion on generics, and especially C++-style templates? Do you see them as a powerful abstraction mechanism, or as something that eventually makes languages and compilers unnecessarily complicated?

Personally, my background tends to push me toward static typing. The two main reasons are:

• I like catching as many problems as possible at compile time.
• Once the type is known, the generated code doesn't need to perform type checks at runtime, which can also make optimization easier.

I'm personally quite fond of generics/templates, especially when specialization can produce efficient native code. But I also know how quickly template-heavy C++ can become difficult to read and produce rather spectacular compiler errors. :)

My first iterations of Klyn, the language I'm working on (there's also r/klyn), are therefore strongly oriented toward static typing and compile-time generics. But since I’m still at an early stage and I want the language to appeal to as many people as possible, I think it’s important to keep an open mind, and perhaps your perspectives will make me reconsider this position.

Thank you for your opinion.

Hi everyone,

I am Abinash. I have been building the Lox interpreter in Rust from the Crafting Interpreters book, and I'm at Ch 12. (Repo URL: https://gitlab.com/implabinash/ci)

After this book, I am planning to learn how to build compilers, but I want to take the custom backend approach because I really want to know how compilers are made without any other library or tool. After learning from scratch, I might learn about LLVM or GCC or other tools based in the need/intrest.

So I did some research, and I found some resources:

• Introduction to Compilers and Language Design (https://dthain.github.io/books/compiler/)
• CS 4120: Introduction to Compiler (https://www.cs.cornell.edu/courses/cs4120/2026sp/notes/)
• CS 6120: Advanced Compilers (https://www.cs.cornell.edu/courses/cs6120/2025fa/self-guided/)

While these resources are awesome to learn from, after Crafting Interpreters, I want to take a hands-on approach, just like the Crafting Interpreters book itself, where I want the resources to take me from parsing to resolving to semantic analysis to code generation, and after completing the resources, I will have a working compiler made from scratch.

I found a course teaching that same thing (URL: https://dragonzap.com/course/creating-a-c-compiler-from-scratch), but it's a paid course, and I can't afford it.

So, I need your help to help me find some good resources that will teach me building compilers from scratch with my own code generation backend in a hands-on approach.

Thank you.

Disclosure first, since some subs ask: the compiler-compiler itself (CCS) is hand-written C++ I have built over a number of years with no AI involvement in its code. The website, the packaged use cases and most of the reports linked below were written with Claude Code assistance.

What it is. A grammar file goes in, a generated C++ parser comes out. The generator is self-hosting: the parser for its own meta-grammar is a committed generated artifact, and it is rebuilt from itself in a round trip (compile the meta-grammar, regenerate, diff). That round trip is the primary correctness oracle for the compiler.

The part I think is interesting. Every parse also produces a compact binary form of the document. That binary is language-agnostic: per-grammar modules are generated for C++, Java, Python, JavaScript and Rust, each sits on a small per-language runtime, and each runtime loads the binary and decompiles it back to source text. The five outputs are compared with plain diff and must be byte-identical. That diff is the whole cross-language verification story. It replaces "our test vectors agree semantically" with "the bytes are the same."

Numbers (public JSON corpora, g++ -O2, 100 iterations): the raw binary loads within roughly 2× of simdjson DOM on twitter.json, citm_catalog.json and canada.json, and 20–30× faster than the same content in the decimal-text form. I am not claiming to beat simdjson. I am claiming that a grammar-driven binary which is generic over formats lands in the same ballpark.

Applied so far to HL7 v2, X12 EDI envelopes, COBOL copybook data, a multisig custody model, and MeTTa as a full language. Reports for each are on the site.

Honest limits. The compiler is not open source; the runnable use cases and the demo code are published. No Go, no C#. No RPC layer. The obvious "why not protobuf" question has its own page, because the answer is "different problem": protobuf invents a wire format for data you control, this reads formats that already exist.

What I would like critique on:

1. Byte-identical decompilation across five runtimes as the oracle. It catches every parser-vs-runtime disagreement, but it passes when all sides are wrong in the same way. What would you add alongside it?

2. Shipping one grammar to five host languages: generate per-language modules over a hand-maintained runtime (what I do), or generate the whole reader? Where have you seen each break?

3. The binary-vs-text crossover. For a load-many-times workload the binary wins immediately. For parse-once workloads it does not. Is there a standard way to present that honestly without it reading as a hedge?

Links: overview paper b3u.dev/docs/CCS_Compiler_Compiler_arXiv_Draft_0.1.pdf, benchmark harness b3u.dev/usecases/ccs_json_bench, the protobuf comparison b3u.dev/docs/why_not_protobuf.pdf.

Hey everyone,

I know the community is flooded with toy languages and AI-generated wrappers, so I want to be 100% transparent upfront: I built this project, Nyx, with heavy AI assistance as a pair programmer.

However, my goal wasn't to generate a quick gimmick or dump unverified code on GitHub. I wanted to deeply learn compiler engineering from the ground up, and I treated the design and testing with extreme rigor.

What the project actually is:

• A statically typed systems language focused on developer ergonomics and zero-cost safety (no garbage collector, RAII scope guards, and deterministic defer).
• Architecture:
  • Frontend: Recursive descent parser -> AST -> Semantic TypeChecker.
  • Middle-end: An authoritative Typed HIR (High-level Intermediate Representation) pass pipeline with reachability-based dead code elimination and deterministic constant evaluation.
  • Backends: Multi-target codegen emitting modern C++20 for native performance, and a direct WebAssembly binary emitter (wasm_ir) with linear memory alignment.
• Verification: 138-case end-to-end regression test battery running on Linux, Windows, and macOS GitHub Actions runners, plus a self-hosting verification stage.

Why I’m posting here: I'm not here to claim this will "replace C++" or compete with production languages. I genuinely want feedback from experienced compiler engineers on the architecture:

1. C++20 vs Direct LLVM: Right now, lowering Typed HIR to C++20 allows me to leverage existing battle-tested optimizers without spending a decade writing machine code generators. For those who built production compilers: at what point does transpiling to modern C++ become a hindrance compared to targeting LLVM IR directly?
2. WASM Linear Memory Alignment: In the WASM backend, I map Nyx structs with an 8-byte deterministic layout to mirror native offsets for zero-copy buffer sharing. Are there subtle edge cases or padding traps with WebAssembly linear memory that I should watch out for?

The repo is open source here if anyone wants to inspect the HIR or test suite: https://github.com/justsomeone-e/nyx

Any constructive critique, architectural roast, or advice on the middle-end design is very welcome. Thanks for your time ;)

[Need Help] Can you guys please suggest me some DSA questions and genral compiler questions in the interview, recently I have been getting lot of call for this

It will also be very helpful if you can share your compiler interview experience.

My background: working on hardware backend, for compute optimisation

im a computer science student in my 3rd year

ive a project worth 30 marks and I'm solo.

ive to submit a project for the compiler design maybe any one/two module like lexical, syntax part or any of the compiler phase.

she told us to do something related to application of the compiler part.

in my review 1 I did compiler security scanner in which we use lexical and syntax module of compiler to find any vulnerabilities like hard coded credentials, buffer overflow or more in the code by constructing Syntax tree.

but I'm not so sure about that.

if you guys can help me with the topic and the idea.

I’m working on compiler development, mainly LLVM, and one issue I keep running into is that whenever Apple releases an SDK update, my existing build becomes obsolete and I have to rebuild a large portion of LLVM from scratch. This ends up wasting a lot of time.

I’ve tried using Docker containers to isolate the build environment, but the builds are significantly slower.

Is there a better way to handle this? How do you guys manage LLVM/compiler builds across macOS SDK updates without having to do a full rebuild every time?

In this article I talk about the engineering feats that went into the development of Wasmi 2.0 which is a bytecode interpreter for WebAssembly. The article is very technical in parts and so I thought this audience might enjoy it. :)

Just recently ended up fixing some bugs and improving on the existing implementation of the LSP.
Now it is able to support labels and also soon features itself as a part [sim8085](https://github.com/debjitbis08/sim8085/) with this [PR](https://github.com/debjitbis08/sim8085/pull/76).

In case you didn't know, this is my second time posting about this project. This project had been almost complete from a long time, yet I had been struggling with working on the integration of it with any existing projects (due to lack of). After some decisions, I ended up using AI and generated a nice draft of the WASM integration required for it to be able to run with the [CodeMirror](https://codemirror.net/).

PS: I really don't prefer the use of AI, but since this had been a blocker for a few months and seemed like a good place to clean up and push through the changes that had been the queue for long.

[https://github.com/shri-acha/lsp85\](https://github.com/shri-acha/lsp85)

I originally wrote ABC as a small C-like language for my Introduction to High Performance Computing course.

The idea was to give students something simpler than C/C++ while keeping the parts that matter for understanding how programs actually map to a machine. During the course, they design a simple RISC-like architecture and write their own compiler for it in ABC. The resulting compiler, not-abc, eventually became self-hosting.

Over time, ABC itself has grown beyond what was strictly necessary for teaching. It now has multiple backends, including LLVM, and I have just tagged the first release, v0.1.

The main new experiment in this release is C interoperability.

Until now ABC didn't need an ABI layer for its teaching use cases. I wanted a practical example for developing and testing one, and chose raylib. There are now a few raylib examples ported from C to ABC, which also makes it possible to use ABC for small graphical programs in class.

At the moment this implements only a subset of the x86-64 System V ABI — enough for the raylib examples and deliberately still a proof of concept. The ABI code is structured so that other targets can be added; ARM is the obvious next one.

ABC v0.1 has also been tested with LLVM 17 through 22.

ABC: https://github.com/michael-lehn/abc-llvm

I'd be very interested in feedback, particularly on the ABI design. Contributions for other targets, more raylib examples, or experiments with other C libraries are very welcome. :-)

Hello everyone! I made my first step into toolchain development by writing a RISC-V 32/64 ELF assembler from scratch, which supports the `g` group extension (along with small others). It has been a way to learn about assembly, C and ELF all together.

It has been quite a journey, and I've shared my learning and thoughts in this blog post which I think you may appreciate, especially if you're thinking to start writing your own.

The assembler is partially based on GNU as design, and it's not a toy encoder: it can achieve relocatable object file equivalence on non-trivial sources like SQLite3 amalgation, while being much "simpler" in its implementation!

Thank you for reading, and I greatly appreciate any feedback!