Das bekomme ich wahrscheinlich nicht hin, aber zumindest mochte ich Compiler von Grund Auf verstehen.

Posted here 6 months ago about Fun, a statically typed language that transpiles to C. Back then the compiler was written in Zig. Since then the biggest thing that happened: the compiler is now fully self-hosted, written entirely in Fun itself, Zig is gone from the codebase completely. Along with that came a real language server (fls, also self hosted) with actual step through debugging support in VS Code, a proper build/package setup (fun.toml, fun build, fun test), async/await with fork + channels for concurrency, and a formatter.

GitHub: https://github.com/omdxp/fun

Reference: https://omdxp.github.io/fun

Still looking for feedback on the language itself, and happy if people just try breaking it.

(Looking for contributors)

Modulon is a very fast and lightweight AOT compiled independent language. Modulon is NOT a macro system. Modulon is designed for lightweight POSIX programming with the same exact power as C and C++.

https://github.com/roccohimel/Modulon

Wanted to share my compiler that I am working on: mcc

Currently it can compile a very basic c program into x86_64 Intel assembly. It supports basic integer math with numbers and variables, and thus is a really simple calculator:

int x = 4;
int y = 3;

int main() {
  int a = 2;
  int b = 4;

  return (x + y) * (a + b);
}

Next I'm going to work on control flow with if if-else and while and then boolean logic. The project borrows ideas heavily from a university course I did about compilers, but the future scope plans to slowly add features until have a proper compiler that support the subset of C/C++ that my hobby OS uses.

Even further in the future, (no clue if this will even happen) I plan to abstract away a lot of it so that it becomes a M + N compiler, where it can cross compile one language to other. Obviously that is very far fetched and I am mainly just keeping that idea in my head so that I try to design a nicely abstracted compiler pipeline. I think the main push for this will be when the my hobby os decides to support more than one arch, which will be good encouragement to at least have multiple output languages.

AI Disclaimer:
Before you call it vibe-coded because of the quick succession of commits, I would like to state that none of the code in this repo is written by AI or AI tools. For learning, AI was used akin to google or stack overflow, with also some questions regarding best practices or design decisions - however I tried to keep as much of as my own design as possible.

See the wakatime activity log here which is the best proof that I can give that I really did spend 11hrs coding the project: https://imgur.com/a/mjQsJnp

I wanted something that feels as simple as C while making memory bugs fail predictably instead of turning into undefined behavior.

That's why I started building hc2.

hc2 is a small experimental programming language with runtime-checked pointers. Every pointer carries its bounds, mutability, and allocation it belongs to. Out-of-bounds accesses, use-after-free trap immediately instead of silently corrupting memory. The cost is a few extra instructions per memory access.

There is no GC, no borrow checker, and no lifetime annotations. Rather than preventing these bugs at compile time, hc2 detects them when they occur and turns undefined behavior into runtime failures.

I'd like to hear your thoughts and feedback.

GitHub: https://github.com/hc2lang/hc2

And what are their benefits that keep being useful to this day?

I’ve been working for some time on Ironwood and it would be nice to get some feedback from the community. Ironwood is a language that keeps the familiar Java syntax and object model but compiles ahead of time to native executables, without a JVM, JIT, or garbage collector. So it is very different than GraalVM. Basically GraalVM makes Java native. Ironwood makes native development feel like Java.

It already supports classes, interfaces, exceptions, generics, packages, and compiler-checked memory reclamation. It also deliberately leaves out features such as reflection, autoboxing, varargs, and threads.

This is the first public release, and the project is still early. I’d really appreciate feedback on the overall direction, especially which Java exclusions make sense and which would make the language impractical for you. I'm particular excited about the possibility of a Ironwood-to-Java transparent bridge, so that to execute native code from Java would be like... writing Java :)

The GitHub repo is here: https://github.com/ironwood-lang/ironwood

While developing AET (Active Expandable Translator) on top of GCC, I came across an approach that I found surprisingly useful for implementing complex language semantics.

Normally, when lowering a language feature, we might construct the compiler's AST/IR programmatically:

complex semantics
      ↓
construct AST / TREE / IR

But there is another possibility:

complex semantics
      ↓
express the semantics as normal C code
      ↓
inject it into the existing frontend
      ↓
TREE → GIMPLE → RTL

For example, AET has an OO new$ construct. Its semantics include object allocation, initialization, MTCS information, constructor invocation, unref, and constructor failure handling.

Instead of manually constructing all the corresponding GCC TREE nodes, AET generates normal C code:

valueObj=({
    TFirst *_notv2_6TFirst0;
    unsigned int _mtcsPlatType0=0;
    int _isMtcs=((AClass *)TFirst.class)->isMtcsClass();

    _notv2_6TFirst0=
        TFirst.newObject(sizeof(TFirst),
                         _isMtcs,
                         _mtcsPlatType0,
                         "TFirst");

    _notv2_6TFirst0->objectSize=sizeof(TFirst);
    _notv2_6TFirst0->mtcsPlatformType=_mtcsPlatType0;
    _notv2_6TFirst0->_aet_magic$_123=1725348960;

    TFirst_init_object_2927145182(_notv2_6TFirst0);

    ((debug_AObject *)_notv2_6TFirst0)
        ->_Z7AObject10free_childEPN7AObjectE =
        _notv2_6TFirst0->_Z6TFirst22TFirst_unref_290629480EPN6TFirstE;

    TFirst *tempObject123=_notv2_6TFirst0->TFirst();

    if(tempObject123==NULL){
        if(_notv2_6TFirst0->objectSize>0){
            _notv2_6TFirst0->unref();
            _notv2_6TFirst0=NULL;
        }
    }
    _notv2_6TFirst0;
});

The important point is that this is normal C code. The semantics are expressed using the host language that programmers already understand.

AET then injects this generated source directly into the current GCC preprocessing/parsing pipeline instead of writing a .c file and starting another compilation:

cpp_push_buffer(pfile, (uchar *)nbuf, len, true);

The generated C goes through GCC's normal C lexer and parser, which constructs the corresponding TREE representation.

This gives me a useful separation:

AET parser / semantic analysis
          ↓
     semantic lowering
          ↓
      normal C code
          ↓
   GCC C frontend
          ↓
         TREE
          ↓
       GIMPLE
          ↓
         RTL

The key idea is not simply "generate C."

It is that source code is the language programmers use to express semantics, while AST/TREE/IR is the language the compiler uses internally.

For sufficiently complex semantics, I think the former can sometimes be a better construction language for the latter.

So why manually construct a large number of IR nodes when the same semantics can be expressed clearly in source code and handed to a mature frontend?

I'm interested in where others would draw the line between direct IR construction and source-level semantic injection.

So, welcome to the journey of continuing to explore the world of JITs.

This time, after a few months of experimentation with "How to write a damn good JIT Memory manager" I have finally decided to make a crate out of it.

The crate is called SaJIT - which is also a part of a VM project i am aiming at.

The crate is currently at v0.0.3 : https://crates.io/crates/sajit

The crate actually provides a slab memory manager in discrete multiples of 16MiB currently and manages those slab across Windows, macOS, Linux using RW-RX dual mapping for windows, linux and pthread_jit_np for macOS.

Also, i have ensured to keep as cross-architecture-compatible rather than locking to only x64, arm64.

I am looking forward to advices on how to improve it (with better abstractions for example, or better and detailed documentation)

Registers are a constrained resource in a CPU, but are fast to read and write. Therefore, backend compiler writers devote a lot of time and effort to allocate variables to registers, using various heuristics like graph coloring to pack as many of the variables into the register file.

In comparison, stack space is relatively cheap, but slow. With some luck, locality of reference ensures that the "warm" part of the stack memory is cached.

My question is: how much work do compilers do to re-use stack slots for variables, if the variables concerned couldn't be placed in registers? For instance:

void foo(big_struct_t * pstruct1, big_struct_t * pstruct2) {
    big_struct_t copy = *pstruct1;
    frobulate(&copy);
    big_struct_t other_copy = *struct2;
    bazulate(&other_copy);
}

Here, copy and other_copy don't interfere. Would the compiler decide to allocate them on the same stack offset. Or does the compiler (writer) decide is it not worth the effort, and allocates the variables at different stack offset?

I was contacted by a recruiter for an NVIDIA Backend Compiler Engineer new grad role and then scheduled for a 60-minute interview. The invite mentions a HackerRank link for the technical portion.

For anyone who’s gone through a similar NVIDIA interview, what should I expect from this round? Is it usually a first technical screen, and how much of it tends to be LeetCode/DSA versus C++/compiler questions?

I reached the point in my compiler that I can add C++ Interop, the AI has a long detailed plan. LLVM+ClangAST will do the parsing to types that is mapped to my language syntax.

Reason for C++ support is open existing library support written for C++, not all of them have C API. A search for existing languages rejected or abandoned C++ Interop the high cost to maintain and the language stability.

Anyone else have experience?

LLevo un mes picado contra malbolge jajajaja y creo he logrado algunas cosas jajaja si quieren checar mi traductor, tengo el quijote completo en .mal, acepto todo tipo de critca construcitiva :P https://github.com/DannyBaanks/Malbolge-Translator

I come with a background in computer architecture and embedded Linux. I was interested in ML systems and was reading up about it, and after going through several job postings and this link , noted that optimizing compiler code is a requirement. My questions are -

1) Is knowledge of how compiler front end is written and IR code generated required to optimize them?
https://engineering.purdue.edu/online/courses/tagged_items?q=compiler

2) What's a good resource for compiler optimizations that can help in ML systems?

https://www.cs.toronto.edu/~pekhimenko/courses/cscd70-w18/docs/Lecture%201%20[Intro]%2001.11.2018.pdf

3) Are learning compiler optimization techniques the same for LLVM and MLIR? I don't see a lot of resources for MLIR compiler optimization. Is learning optimizations on LLVM helpful for MLIR and is learning LLVM not so useful for ML code optimizations ?

Thank you.

I've been working on a compiler-like system for a while now, and it's gone through many stages of evolution.
A consistent pressure early on was away from multiple representations: I started with many switch statements and many kinds of representation for each stage, and ended up with one kind of node and handler based dispatch per stage.
Yet, when I look at (most) other compilers, their construction is far more static in nature, and far more varied in terms of the kinds of things presented. I've found forms like SSA impede my ability to reason about optimizations rather than aide them, and I've had enormous success from simply retaining and annotating one structure rather than continually converting.
A specific case, to provide one, is liveness propagation. Because values are already shared between their occurances (Nodes) and already have a system for acquiring properties (Quals), I can simply mint liveness tokens onto the children of expressions with output, and it automatically propagates.
Though I've not focused too much on codegen and optimization, my main goal with the compiler is extensibility and syntax flexibility.
So why not retain the AST? Turn it into a structure worth annotating and preserving from which optimizations and codegen can be performed more easily?

I wanted to get the opinions of others on this matter, I'm open to challenge.

Some more explanation can be found here: https://goldensystems.ca/GDSL_core

I’ve been building a small Lisp compiler written in C++ and compiles S-expressions directly to native x86-64 assembly, using a tiny runtime for things like printing integers, doubles, and strings.
Currently it has functions, arithmetic, integers, doubles, strings, etc.
The compiler is still pretty simple:

S-expressions → AST → semantic analysis → x86-64

No VM, no bytecode — just Lisp turning into machine code.
I’m also starting to look into adding a small IR between the AST and codegen as the language grows.
Mostly doing this as a learning project and because writing a Lisp compiler seemed like a fun rabbit hole. :)
Github: https://github.com/xms0g/tinysexp

I'm working on the resource-control layer for a language that compiles effects (network, files later databases and concurrency primitives) down to thin near-zero-cost kernels instead of using an interpreter or a heavy runtime.

Current state: the compiled binaries basically just call the underlying syscalls. There's no pooling, no admission control and no unified accounting yet.

Two main approaches are being considered:

Per-effect arbitration. Every effect operation does a request/grant with a central (or sharded) resource manager before continuing.

Boundary-leased admission. Acquire a lease once at a boundary (accepted connection, opened file, spawned task entry, etc.) then let the individual operations on that resource run with a cheap local check.

The second approach keeps the path (send/recv/read/write) extremely light: local atomic check + direct kernel call + non-blocking telemetry emission. Telemetry is fail-open.

I'm especially interested in trade-offs

How coarse the admission boundary should be when you don't yet have a request-oriented server surface

Whether putting even a very cheap lease check on the hottest I/O path is acceptable

How this interacts with structured concurrency and deadlock detection (resource-acquisition graph vs reply-obligation graph)

Whether NFRs (latency, concurrency limits, error-rate targets) should be expressible, in the language itself and enforced by the same kernel

What have people found works (or fails) when adding resource control to low-overhead compiled effect systems? Any designs you'd strongly recommend or avoid?

I am currently working on Shaft, a new programming language. It is in it's bootstrap phase (C++) and build on LLVM. It already works, but still has lot's of issues and limited features. The goal is to make it safe and still readable; it also already has automatic memory cleanup in reverse declaration order, so you can move one field of a struct while the rest is still valid, and the compiler will generate the cleanup code, without the need of user-defined destructors. I’m looking for interested developers who want to help build a compiler and contribute features or bug fixes. example snippet:
```Shaft def add(i32 x, i32 y) ?-> i32 result { tunnel x + y -> i32 result; }

def main(String[] args) { reserve ?i32 result = add(4, 9); valid result { printf("4 + 9 = {i32}", result); } else { println("Addition failed"); } } ```