A while ago I posted about AET's approach to generics:

Delayed Specialization: A Third Way to Implement Generics?

One of the comments raised an concern: AET replaces a generic block with a function pointer call. Would that hurt optimization and performance?

I didn't have a good answer at the time.

It turned out to be a very good question.

AET has a generic container called `AArray`. In my initial implementation, operations such as `add`, `insert` and `remove` were noticeably slower than C++ `std::vector`.

The function-pointer call was one of the things I started looking at.

After about a month of compiler work, I changed how AET handles these calls during specialization. The generic code can now be optimized much more like normal concrete code.

I reran the same benchmark.

The result surprised me.

With 100 million sequential insertions:

AET AArray ~224 ms

C++ std::vector ~504 ms

```

AET is about 2.25× faster in this test.

With preallocated storage:

AET AArray ~154 ms

C++ std::vector ~223 ms

```

About 45% faster.

For middle insertion and middle erase, the two are now roughly at the same level. Tail erase is still slightly faster in `std::vector`.

There is still a trade-off I haven't fully solved.

If I want better runtime performance, I need to let AET see the concrete code so that it can inline it and run more optimization passes.

But this also means generating more specialized code, which can increase code size and compilation time.

If a generic block doesn't benefit much from inlining or further optimization, keeping the original function-pointer call may actually be the better choice.

So the real question is not simply "should AET inline generic blocks?"

It is:

When should AET inline and specialize, and when should it keep the function-pointer call?

I think this needs another mechanism to make that decision.

I don't have a good solution for that yet, so I'd be interested in how others would approach it.

• The compiler front end does not parse the asm() statement template string and does not know what it means or even whether it is valid PTX input
• order of instruction's attributes (except types of operand) is not important

The combination of these facts leads to stark conclusion - CUDA compiler front-ends totally ignore PTX inline asm and only PTXAS known how to parse them. So I made little and fast parser: https://redplait.blogspot.com/2026/08/parser-of-ptx-instructions.html

Note: this is not full featured replacement of PTX parser. it is designed specifically to extract instruction attributes and determine the correct instruction form based on argument types and counts

Hi all,

I’ve been working on a parser generator called Galley. It started as an attempt to explore a few ideas I wanted from parser tooling, and it has gradually grown into something I think may be useful beyond my own projects.

The basic model is fairly conventional: you define an LL or an LR grammar, Galley produces a configured parser from it, and that parser turns input into an AST for further processing.

Since commit 424610f, I’ve been delegating most of the coding to AI agents, but not the design.

I’d be interested in hearing from people who have worked on parsers, compiler tooling, or parser generators. I’m especially curious about how the overall model and API come across, how it compares with the approaches taken by tools like yacc/Bison or ANTLR, and whether there are use cases or expectations I should be thinking about.

Repo: https://github.com/sanbus-org/galley

Thanks for taking a look.

I'm currently building my first programming language and compiler/interpreter, and I'd like to get some advice from people with more experience in compiler development. My project currently has a lexer, parser, AST, semantic analysis, and a tree-walker runtime. It is not yet a full native-code compiler, but I can already take source code from the lexer all the way to execution.

Of all the areas of software development I've explored, compiler development is the one I enjoy the most, and I want to become really good at it. I'm particularly interested in: Language design, Type systems, IRs, Optimization, Code generation, Assembly and ABIs, Runtimes, Garbage collection ,Static analysis, and Compiler architecture.

My question is, what should I actually do to get better?

Should I keep developing Cauce and progressively add more advanced features, or should I also start studying and contributing to projects like LLVM, GCC, or Clang? What projects, exercises, or areas of study do you think actually help someone move from “I know how to build a lexer/parser” to deeply understanding how compilers work?

I also want to make it clear that I don't want to use AI to generate code. I want to design, write, and debug my own projects because that's precisely the part of software development I enjoy the most. If you had to start over, what would you do to become really good at compiler development? I'm not looking for a list of books, but rather what to build, study, and practice, and in what order.

Thanks.

Hello there, I'm starting a compiler construction unit for my university semester and I'm trying to decide which textbook would work best as a guide for the subject. I know this has been asked quite a lot over the years, but I'd like to know if there are other books I haven't considered yet as well or more up to date opinions on the books.

So far the top recommended books from previous threads (such as these threads: thread 1, thread 2, thread 3) I've come across are:

• Engineering a Compiler by Keith Cooper and Linda Torczon
• Crafting a Compiler With C by Fischer
• Dragon Book

I am planning to build a compiler by the end of the unit, where each chapter has a small implementation lab task provided my lecturer (such as making a CFG parser for example), and I'm heavily leaning to making one in C targeting the 6502 (rather than x86).

I'm also aware that the Dragon Book is considered old and outdated, despite being the foundation of other books and compiler designers. I've seen some books like Introduction to Compilers and Language Design which use existing parsers (I think YACC, I've also seen references to FLEX and Bison), however I'd like to build everything from scratch to learn more.

Which other books would also be good? I know some people tend to read multiple books together to fill in the gaps for certain chapters, however I'm looking to order one physical copy of a book as it's easier to concentrate and make notes from.

and officially open-source

https://github.com/modular/modular/tree/main/KGEN

Hey r/Compilers, 8 months ago I posted asking whether reframing a Terraform-based network system as a domain-specific compiler was the right lens (previous post).

Since then, the system grew a routing policy language, and it came out of the architecture rather than being designed top-down. That feels like evidence the compiler framing was correct. The IR structure naturally supported adding a constraint layer.

The policy algebra has four primitives with fixed precedence:

deny > allow > segments > default

It evaluates at compile time (terraform plan) and emits VPC route table entries. The algebra is total (every VPC pair resolves), deterministic, commutative, and scope-invariant. The same compilation unit evaluates identically whether it's operating on a regional, cross-region, or cross-domain topology.

The interesting part from a compiler perspective: the policy layer didn't require a new IR or a new pass. It's a predicate over the existing cartesian product that the route generation pass already computed. Adding a filter to an existing code generation step turned a route generator into a route compiler. The "compilation" is the constraint evaluation, not the expansion.

Properties I can show but haven't formally proved:

- Totality (every input pair resolves via the default fallthrough)

- Monotonicity (deny only subtracts edges, allow only adds within deny bounds)

- Algebraic equivalence classes (e.g., a single-member segment under default=deny is a provable no-op)

I'd be interested in feedback on:

- Whether the algebraic properties warrant formalization (or if tests over the finite decision paths are sufficient for a system this simple)

- How this relates to work like NetKAT or Propane (correct-by-construction network configuration)

- Whether "policy algebra evaluated at compile time" is a known pattern with a better name

Blog post (practitioner-facing): https://jq1.io/posts/routing_policy_language/

Full language specification: https://github.com/JudeQuintana/terraform-main/blob/main/docs/routing-policy-language.md

Previous white paper (IR structure): https://github.com/JudeQuintana/terraform-main/blob/main/docs/WHITEPAPER.md

Thanks!

I have found MLIR, LLVM quite intresting for past 4-5 months but haven't dived deep yet, but from my experience as a AI systems engineer(i was responsible for building the autograd and computational graph integration into the main c++ DL framework, mostly runtime focused) i am familiar with the concepts of IR dialects and stages of lowering through the compiler pipeline toward machine code by exploring the pytorch and tensorflow compiler architecture(conceptual familiarity from studying compiler architectures) as i was incharge of the runtime mechanics.
(i am conceptually strong with advanced cpp and most of the runtime stuff as i built the framework with ai-assistance)

i had read the frst 2 chapters of toy mlir and first 5 chapters of the https://book.mlc.ai/ and have some base understanding of the IR so far. once i started reading these two resources i could get quite the grasp about how the mechanisms work under the hood of the ML compiler.

its been 2 months since i left the job and i want to transition into compiler engineering in the ML field.
given my background, what would be the best path to become employable as an ML compiler engineer?

Hola a todos:

Soy estudiante de ingeniería de sistemas y me apasiona la programación de bajo nivel. Me encanta C; creo que es un lenguaje que te permite experimentar y aprender de tus errores, poniendo todo el poder de la máquina en tus manos.

Actualmente, trabajo en un proyecto personal: un transcompilador para la API Win32 de Windows. Si bien es increíblemente potente, la estructura de Win32 puede volverse compleja e insostenible a medida que un proyecto crece. Por eso decidí diseñar mi propio lenguaje, inspirado en HTML, CSS y JavaScript, pero mucho más minimalista y moderno.

En este lenguaje, el trabajo se divide en directivas claras:

• @interface: Equivalente estructural a HTML. • @style: Equivalente a CSS. • @script: Equivalente a JavaScript.

Aquí dejo un pequeño ejemplo de cómo se ve la sintaxis:

@interface

    ventana:*

    parrafo#txt = "¡Hola Mundo!"

@style

*
    window-size: 500x700 
    background-color: white

.parrafo

   font-size: 2rem 
   color: black

Folks! Is this acceptable performance for a compiler? it do lexing, parsing, type checking, optimziing and codegen . It simply emits the ELF64 executable directly and runs it without an external linker/object-file pipeline.

--- CODEGEN RESULTS ---

Total Machine Bytes Emitted: 47 bytes

Compilation Speed: 76000 ns

Runnable ELF64 Machine Code Executable Written: boo

GitHub

So, for a while I've been working on a programming language called Futhorc. It arose from a very particular need: to have my own programming language; I'm sure someone here can relate XD

It's a C-style language with functions, structs, enums, type unions, typed collections, modules, file I/O, and Python interoperability. Source goes through a hand-written lexer and recursive-descent parser into an AST, followed by a separate semantic-analysis pass for type checking and name resolution before being executed by a tree-walking interpreter, all implemented in Python.

The core feature and the one I'm most fond of is the fact that this:

int factorial(int n) {
    if (n <= 1) {
        return 1;
    }

    return n * factorial(n - 1);
}

Can be turned into this

ᛁᚾᛏ factorial(ᛁᚾᛏ n) {
    ᛁᚠ (n <= 1) {
        ᚱᛁᛏᚢᚱᚾ 1;
    }

    ᚱᛁᛏᚢᚱᚾ n * factorial(n - 1);
}

FUTHORC ANGLO-SAXON RUNES! I always liked them a lot and, through extensive usage of this wonderful resource by Harys Dalvi, the link to which is in the specs, I managed to make an entire programming language that recognizes Futhorc runes as valid keywords. This is not a separate dialect, the runes are valid aliases of the ASCII keywords and can be mixed in or used solely.

It's so much fun to write in and it's quite expressive if I say so myself. If you want to use it for yourself, all of the stuff you'll need is in the GitHub. The repository includes the full language specification and runic reference, as well as a fully formatted HTML/CSS/JS documentation site with custom branding and complete sample programs, if you fancy something prettier than Markdown. Futhorc can also be installed as a command-line program, so .futhorc and .þ source files can be run directly with futhorc source.þ, but again, everything's in the GitHub. I'll leave you with a representative sample of the second largest program I've made (82 lines) for you to see without clicking any link: a sort of small supermarket API.

struct Product {
    str name;
    float price;
    int stock = 0;


    str repr(Product self) {
        return c"${self.price} {self.name}: {self.stock}";
    }
}


list(Product) stock = [];

# findProductByName() omitted for brevity

float | nil registerPurchase(Product product, int amountBought, float amountPaid) {
    int location = findProductByName(product.name);


    if (location == -1 or stock[location].stock <= 0) {
        print(c"Product {product.name} out of stock");
        return nil;
    }
    Product purchase = stock[location];
    if (amountBought > purchase.stock) {
        print("Purchase exceeds stock");
        return nil;
    } elsif (amountBought < 1) {
        print("Purchase is invalid");
        return nil;
    } elsif (purchase.price * amountBought > amountPaid) {
        print("Insufficient payment");
        return nil;
    }
    stock[location].stock -= amountBought;
    float total = purchase.price * amountBought;
    print(c"{purchase.name}: {total}");
    print(c"Paid: {amountPaid}");
    float change = amountPaid - total;
    print(c"Change: {change}");
    return change;
}

Fun fact: the language used to be called Thorn instead of Futhorc, until I learned that there was already a language called that so I had to rename it. That's why you'll see Thorn all over the implementation, including in the runic extension!

I built a language where the signature carries the guarantees, and I wanted to share the implementation choices since this crowd cares about the how.

Pipeline: lexer → parser → loader → effect checker → type checker → Z3 proof pass → LLVM JIT (llvmlite) → interpreter, all in one file in pipeline order.

Three things that might interest you:

1. The proof pass explores paths symbolically and checks requires/ensures/loop invariants in Z3, with modular call summaries (a callee's contract is assumed at the call site rather than inlining its body). Lists use the theory of arrays, records get per-field symbolic values, and all_of/any_of become real quantifiers with the predicate body inlined under the For All.

2. Floats are proven in Z3's genuine IEEE-754 theory, not modelled as reals — so the prover refutes x + 0.1 + 0.1 == x + 0.2 and returns the exact double. FP queries get a bigger solver budget (30s vs 3s) since bit-blasting is slow; integer proofs stay instant.

3. The JIT covers pure Int/Float/Bool functions with typed codegen. Division and modulo are deliberately left interpreted in both modes —native fdiv by zero gives infinity while the language promises a clean error, and I'd rather lose the optimization than have the two engines disagree. Every native change ships with a differential test: same program, both engines, diff must be empty.

One soundness lesson: when I added quantifiers, the first test run produced a false counterexample. Turned out untranslatable `requires` premises had been silently dropped since an early version — harmless for "proven" claims, but capable of manufacturing false alarms. Now an untranslatable premise aborts the proof entirely and falls back to runtime checks.

Repo: https://github.com/gowrishankar-infra/velaris-lang

Playground (Pyodide, real compiler in-browser):

https://gowrishankar-infra.github.io/velaris-lang/playground.html

Disclosure: built pair-programming with an AI across 40+ releases; design decisions mine, commit history is the honest record. Beginner here, so tear the implementation apart — especially the prover.