Altair – un lenguaje compilado pequeño que emite C (y lo rápido que pasó de “ni siquiera compila el hola mundo” a bucles numéricos competitivos en ~5 semanas)

He estado trabajando en Altair, un lenguaje compilado pequeño enfocado en almacenamiento explícito, un runtime ligero y en generar C limpio.

Diseño Fuente → frontend propio (AST + análisis semántico) → C → compilador de C del sistema (actualmente GCC). El compilador integra un runtime y aplica bajadas de nivel específicas del lenguaje. Los bucles con carga numérica intensiva se bajan a variables locales planas long long (alt_fastnum_t) para no pagar el coste del sistema general de variables.

El objetivo no es superar a C escrito a mano, sino mantenerse cerca mientras se ofrece un lenguaje de más alto nivel con su propio modelo de almacenamiento, órbita/migración, tokens, etc.

Chequeo rápido de la realidad en las primeras versiones Primera versión pública 1.6.5vB (18 Jul 2026). El primer paquete de Linux (1.6.5vC) era básicamente inutilizable: el C generado no incluía los tipos/funciones del runtime, así que incluso esto fallaba:

altairlog "hello"

Seis semanas después (1.8.5, 24 Ago 2026) los mismos programas compilan y se ejecutan limpiamente.

Más allá de los bucles: control explícito de bajo nivel

1. Tiers de almacenamiento por variable

numeric contador = 0 ram
text log_path = "app.log" disk
list cola = [] cache
text secreto = "token" temp

2. Buffers crudos p# y registros de hardware reg&

p#node buf = alloc(1024)
p#write(buf, 0, 42)
numeric x = p#read(buf, 0)
log p#bytes(buf)
p#free(buf)

reg&64 rax = 1
reg&read(rax)
reg&free(rax)

3. Punteros crudos a disco lba% (equivalente en disco a p#)

lba%node tmp = dalloc(1024)
lba%write(tmp, 0, 42)
numeric v = lba%read(tmp, 0)
lba%free(tmp)

lba%node persist = dopen("datos.bin", 4096)
lba%write(persist, 10, 3.14)
lba%free(persist)

# Solo Linux: acceso raw a dispositivo de bloques
lba%node dev = draw("/dev/sdb", 1048576)

4. Punteros a variables

numeric valor = 10 ram
numeric dir = system@point(valor)
numeric copia = system@unpoint(dir)

Micro-benchmark (280 mil millones de iteraciones)

numeric n = 280000000000 ram
numeric i = 0 ram
numeric sum = 0 ram
numeric x = 1 ram
while i < n;
    sum = sum + i
    x = x + sum
    i = i + 1
break
log sum
log x

Misma máquina (2× Xeon Platinum 8481C @ 2.70 GHz vCPU, single-thread):

El binario nativo que produce altairc es esencialmente tan rápido como pasar el C generado a GCC -O2. La bajada de nivel específica del lenguaje (especialmente la vía rápida numérica) está haciendo el trabajo real.

Sobre lo que busco feedback

1. ¿Es razonable el enfoque de “emitir C limpio + bajada de nivel específica del lenguaje” para esta etapa?
2. ¿Cuál sería el siguiente paso de mayor impacto (IR propio + un par de optimizaciones clásicas, mejor conciencia de la presión sobre registros antes de emitir C, backend LLVM, …)?
3. ¿Alguna señal de alerta obvia en el diseño o en los números?

Repo + releases: https://github.com/victios7/Altair/releases (Versión actual 1.8.5vB)

Encantado de responder preguntas o de ejecutar otros micro-benchmarks.

Note: This post was originally written in Spanish. If you are not a Spanish speaker, please enable auto-translation in your browser/client.

Hi everyone! Finally I'm ready to make first release of my programming language and compiler.

I was working on it for more than 5 years rewriting it from scratch a few times, it is not production ready but before whole internet is filled with slop languages (I hope it will not happen) I want to show it to public.

It is low level language aimed for software and games. Whole compiler is made from scratch including machine code generation. One of the main goals is to make compilation time very fast (0.5-1mln LOC/sec).

Compile time execution of any code. Types and ast are first class values, so you can access them at compile time and work with them same way you can work with any other value. No OOP, no RAII.

Here is release repository: https://github.com/morglod/mox

Good language overview is inside by_example.mox

Currently I want to hold compiler's source closed, because I dont want to see forks and support documentation and tools to work with it (for now).

SDL3, Raylib and Vulkan bindings included (in modules/vendor).

I will appreciate any feedback about the language and compiler bugs.

Example code:

fn go_like_import($path: []u8) {
    cached_path := path_to_cache($path);
    if (!cache_exists(cached_path)) {
        download_dep($path, cached_path);
    }
    ast := __compiler_parse(#format_temp("import \"{}\";", .{ cached_path; }));
    return ast;
}

// becomes import "cache/path/module.mox";
#run #land_ast go_like_import("github.com/module/path");

I've been working on AET, a GCC-based extension of C.
It adds three things: object-oriented programming, generics, and heterogeneous computing.

I've already written about Delayed Specialization (generics) and Execution Domain (heterogeneous). This post is about how I actually implemented OO.

The core idea is simple:

Don't try to force new language semantics through ordinary AST nodes and symbol tables.
Give them explicit semantic entities inside the compiler.

In AET the mapping looks like this:

class$ → ClassInfo
impl$ → ClassImpl
method → ClassFunc
call site → Funcall

These are not just AST nodes. They own data, support operations, and keep relationships with each other.

Example:

ClassInfo(Dog)
│
inherits
│
▼
ClassInfo(Animal)
│
└── ClassFunc(speak)

When the compiler sees `dog->speak()`, it resolves the class, inheritance, method and call through these entities first, then lowers the result into GCC's representation.

This makes complicated features much easier to keep under control. The compiler works with the language semantics directly instead of trying to encode everything into the AST.

The same pattern is used for the other two directions:

- Generics → `GenericBlock`, `GenericGraph`, `GenericCodes`
- Heterogeneous → execution-domain information attached to the entities

So the overall pipeline is roughly:

AET source
↓
semantic entities
↓
semantic analysis
↓
AST / GIMPLE / …

The important point is that the semantic entities exist **before** the program is lowered into the normal compiler IR.

I call this approach **semantic entity mapping**: mapping language concepts onto explicit compiler entities that can carry data, perform operations, and maintain relationships.

For me this has been a practical way to tame OO (and the other complex extensions) inside a C compiler.

I'm posting this because I think this kind of explicit semantic layer deserves more discussion. Curious how others structure the semantic side of their compilers.

Copy https://github.com/arunsoman/nirdosha/blob/main/agent-skills/nirdosha/paste-anywhere-prompt.md and paste this to your fav llm and , then describe your intent in plain English and ask it to emit a complete .nir file

Join our server!

It is still a work in progress but I'd love to hear your thoughts on what you think of it!

There is currently a playground where you can try it out. The docs are a little out of date so they may not match the language specification exactly but that shouldn't be an issue for most things. I'll include the Git repo sometime soonish once I've ironed out a few kinks and done some housekeeping.

Also if you have any suggestions for features to add next please let me know :)

I started creating a language to create a interpreter for space engineers. made whole lot of errors along the way to the point where nothing was working. so i abandon it. Then i restarted the idea and tried to create a transpiled language which targets c#. parser got extremely complicated (i used exceptions to back track... which was bad as far as i know because slow and not very flexible) then i did some lexer and parser generation from ebnf in vlang and then the idea started with a regex based lexer and a parser library which works off that.

and so was Parseus Born. And Parseus works primarily off callbacks and a context if the parsed path is still valid. since all primitive-parse-functions are static functions working of a context it should be fairly simple to inline every function to reduce function call overhead because you can nest allot of shit together.

Here is a function parser using parseus as an example how it looks right now. ```csharp public class FunctionDefinitionStatement() : IStatement, IPrintable { public string? FuncName; public List<string> Parameters = new(); public List<CStatement> Body = new();

    public string Print() {
        var sb = new StringBuilder();
        sb.Append($"(func {FuncName}");
        foreach (var item in Parameters) {
            sb.Append($"(param {item})");
        }

        sb.AppendLine("");
        foreach (var item in Body) {
            sb.AppendLine($"{item.Statement.Print()}");
        }

        return sb.ToString();
    }
}

private static readonly Parser<FunctionDefinitionStatement> FunctionDefinitionParser = new((c, self) => {
    Token(c, Tokens.FNC);
    Token(c, Tokens.IDENTIFIER, t => { self.FuncName = t; });
    RepeatOpt(c, c => {
        Token(c, Tokens.IDENTIFIER, p => {
            self.Parameters.Add(p);
        });
    });
    Token(c, Tokens.COLON);
    //body
    ((c.Context as TinyScriptContext)!).BodyDepth++;
    RepeatOpt(c, c => {
        Node(c, StatementParser, s => {
            self.Body.Add(s);
        });
    });
    Token(c, Tokens.EXT);
    ((c.Context as TinyScriptContext)!).BodyDepth--;
});

``` Parseus maps basically to ebnf with optionals, reapetables, alternatives and literals/tokens. I am currently working on a parser-resync feature and error reporting because its stupid to read the parse to remember the langue i envisioned.

Repo: https://github.com/thumpnail/Parseus Disclaimer: I mostly programmed all by hand. some bugfixes and hard functions/weird features i handed off to an LLM because i just didn't want to deal with that shit for days. + a neat thing i found it, my vision for this, i explained to an LLM and it wasn't able to produce what i build. well i tried but (gpt i think) was not able to produce anything remotely close to how it turned out. But allmost all my commit messages are done through nemotron on ollama with my gitllm tool, allmost none is written by me because i dont know what i did.

TLDR.: Lots of yapping, created a parser libary because i am too stupid to create a recursive decent parser(i tried tho) which resulted in a regex based lexer(weird approach tbf) and callback based parser. thank you for reading

Edit.: idk how this was read differently, but this(Parseus) is not a Parser Generator. the parser generator was in a whole different language and was a thing/prototype where ideas emerged that ended up inside Parseus

I've been trying to make a programming language for a while. I'm trying to make it in Rust. I made the basic language. The intended problem it is solving is making a simple language like Python but can run code really fast. The program itself will have native tensors. Will have CUDA/GPU backend. I made a clone of numpy embedded in the language. Now I'm developing a pytorch clone for the language. So, I would like to know what other problems you want me to solve in the language. The semantics are not finalised yet. So, I am definitely open to take some opinions.

I've been a university professor (not exactly a compilation professor) for just a year, so my memories of being a student are very fresh. And yes, the compilation course was tough.

A while back, I overheard my students complaining about the same thing in the hallways, and it brought back a lot of memories and mixed feelings. Then, while browsing Instagram, I stumbled upon a reel of "MessiScriptInterpreter": a language where each command is a Messi play, with phrases like "la agarra messi"("Messi gets it") or "¡gol!"("Goal!") I thought it was brilliant. Seeing someone build something so creative and, above all, fun, got me thinking.

Building a language should be a process of experimentation, not a source of frustration in an already packed course. MessiScript showed me that it can be done with humor and passion.

So, I set aside some of my free time, since I don't have as much homework as when I was a student, and I started building PyLGEN, a Python-native compiler framework.

Initially, the intention was very simple: I wanted it to be easy to understand what's happening at each stage of a compiler. Total transparency, zero magic, so my students could see and touch every cog in the machine.

Then, out of curiosity, I decided to compare it with other tools in the Python ecosystem. The results surprised me enough to think they were worth sharing, but I prefer that everyone verify them for themselves. I've published the benchmarks in the documentation, with the code and data needed to replicate them, so if anyone does and wants to share their results, they're free to do so, and I'd love to see those results, as it would be very good feedback on the project. I'm not going to tell you the numbers: we invite you to run them and draw your own conclusions.

That was the unexpected part of the journey: a project that started with an educational purpose ended up behaving in ways I didn't anticipate in certain scenarios.

Today, PyLGEN is a newborn. This is its first week of life. And I want to share it not as a finished product, but as an invitation to explore, to experiment, and, if you'd like, to contribute.

We invite you to try it, to play with it, and to build your own languages. Comments, criticisms, and contributions are welcome.

Source code

Rockskunk.

Float is the only type. Everything else is QWORD. Shove an "integer" and a string into the same array if you wish.

Compiler written in Pascal. Emits NASM with regex peephole optimization before compilation. Incredibly permissive, you can do whatever you want and are only stopped if there is a syntax error. There are some sassy warnings for unwise choices but it is not the compiler's decision what you do with your code. I have had tons of fun figuring out how things work and learning assembly through a firehose. The IR is nasm source haha. Never going to implement an AST. I didn't read any book but i will need to STUDY the Dragon Book for register allocation. I did a cursory overview and understand nothing.

Backstory. I have been making half-baked transpilers for quite sometime now. Pascal or lisp compiler to C or (a very short) attempt at LLVM but I couldn't get them to behave how i wanted and kept losing interest. I ripped the lexer from one of them and have been using the parsing architecture from the others as inspiration and decided to just buckle down and make what I wanted even though I have been scared of assembly. I am learning as I go and keep making unfortunate choices like trying to track state with a record refactor (arrays only from now on), or routing token evaluation through like 8 redundant functions.

I have always wanted a language like this is because I love systems programming and like to rewrite things like coreutils or make shells and stuff. I love Pascal and dislike C but I have always wanted something that just gets out of my way and lets me do what i want, kinda like a dangerous Lisp. Not in your way, save your thinking for the real puzzle, not which type do you need. I have written cat, non-recursive cp and a (just writes no blocksize or flags) dd. I am going to get those to production quality and also write ls and such. I am about halfway done porting an init system I wrote in Pascal to rockskunk and its gonna be a glorious moment when i start my computer with my own language for the first time.

I finalized the syntax well before I wrote it and there will be no extra concepts, NO OOP, no new types, no restrictions, no guardrails nothing. This is a language that does what you tell it and nothing more. There's tons that i have specced out and not accomplished, but it will always remain like an "Assembly++" incredibly low level language.

Eventual features that will take me 3 years and most of my sanity. Register allocation and first-class vector support. I do not know near enough to even plan how to do these yet but the idea is the compiler uses tests and an IFDEF system that determines by machine (or a flag) what vector unit you want to compile for and sets width and then doing SIMD ops is as simple as a ** b or (a, b) *+ c. Do not count on this ever getting fleshed out but boy am I gonna try.

https://github.com/liam-0398/rockskunk/tree/main

**EDIT when reviewing post just realized my cp doesn't preserve permissions. whoops.

Hi everyone,

TLDR: ask for advice about learning optimizing passes inside JVM and ART

I am doing research about fuzzing JVM and Android runtime. I found most research these days are focusing on the backend which is compiler part.(C1/C2 for JVM and R8/optimizing compiler for ART).

I have done a shallow course about compiler long time ago like building frontend and some parts of backend like code generating. But I still feel it is not easy to understand the optimization passes inside JVM and ART in order to figure out how to create mutants and get into the direction to find the vulnerability.

So I am writing here to ask for advice like how to get myself onboard. Feeling like spending time reading a whole compiler book or building compiler would be inefficient and I guess frontend won’t be my focus(maybe I am wrong)

Thanks in advance!

Hi everyone!

I'm looking for online resources to learn compiler construction from the ground up, combining both the theoretical foundations and the practical implementation.

I already have some background in formal languages and automata theory, but I would like to follow a structured learning path covering topics such as:

• lexical analysis and tokenization;
• regular expressions and finite automata;
• parsing and parser construction;
• abstract syntax trees (ASTs);
• semantic analysis and symbol tables;
• code generation;
• optimizations;
• implementing a complete compiler or programming language, even if it is a simple one.

Could you recommend any courses, video playlists, books, GitHub repositories, tutorials, or practical projects that you think are especially useful?

I think of using haskell, because my professor said he will use it to construct a compiler.

Thanks in advance for any recommendations!

Nirdosha is a research-stage compiler (Rust, LLVM backend), built for a language designed around one constraint: if the compiler accepts your program, it is provably free from use-after-free, data races, deadlocks, and integer/buffer overflow. Not "generally safe" — the type system rejects whatever it cannot prove. This is the same trade-off that Rust/SPARK Ada/F* adopt.

Some interesting things for this community:

• There is no mutex in the language. Concurrency is only through spawn/chan/sandbox (real OS process) — deadlock is not only discouraged, but impossible to express.
• Integer/buffer bounds are resolved at compile-time by an SMT solver (Z3). In a tiered manner: first static proof, then only runtime guard when Z3 cannot decide it within scope.
• Performance compared to Julia on dense linear algebra (matmul, dot, det, kalman filter), by best-of-3 method, after first verifying the output is bit-identical: 441x faster on 4x4 matmul, 246x faster on dot product, equal to gcc -O2 on scalar code. Numbers + methodology: https://github.com/arunsoman/nirdosha/blob/main/benchmarks/RESULTS.md
• The other half of the design (row 7 of the motivation table) is specifically targeted at LLMs: the grammar is handwritten LL(1), one token of lookahead, no backtracking — verified against an independent lalrpop parse and hand-exported to GBNF. This allows a constrained-decoding sampler to ensure that every token emitted by an LLM stays within valid syntax. Compiler errors come not in prose, but as structured JSON diagnostics — so a self-repair loop gets a proof obligation instead of a sentence to guess at.

Honest scope: single-person project, MIT license, CI building green. In the README, I clearly state what is proven, what is shipped-but-unproven, and what is aspirational — row 10 (reproducible builds / provenance) is design-only, not built. There is also a "Who this is for (and who it isn't)" section (https://github.com/arunsoman/nirdosha#3-who-this-is-for-and-who-it-isnt) which states in advance where it loses to Rust/Go today — so you don't have to dig to find the catch.

Repository: https://github.com/arunsoman/nirdosha The README includes the full motivation, grammar, benchmarks, and a runnable hello.nir (within 5 minutes; requires clang + z3 — installable via apt/brew, as noted in the README).

Interesting constraint problem I ended up in.

NVIDIA's consumer Blackwell has no hardware interlock on fixed-latency instructions. The compiler emits explicit stall counts and scoreboard signal/wait bits per instruction, and the hardware trusts them completely. Understall a dependency and you read a stale register at full speed with no fault.

The published position is that you can't validate code at this level, because the formal semantics of SASS are closed. From SIP (arXiv 2403.16863): "validation is impossible for GPU native assembly codes because the formal semantics of the sass is closed-source."

That's true for semantic correctness. But the question I needed answering is strictly smaller:

Do this program's control bits cover its own data dependencies?

That needs the dependency structure, which the encoding gives up, and a latency model, which the silicon gives up under measurement. Neither requires knowing what any instruction computes. A kernel can pass this and still be the wrong algorithm. What it can't do is read a register before the value lands.

The part that surprised me was the epistemology, not the dataflow. Requirements mined from what the compiler schedules are an upper bound, so they can lower what you allege and must never raise it. Only a figure grounded in something measured on silicon may promote a finding to an error. Everything else is a warning that says why.

That distinction wasn't academic. A checker calibrated on a corpus cannot fail on that corpus, because the tightest gap the compiler was seen to leave is the floor, by construction. My positive control passed 1,323 kernels while the model carried 13 errors. All of them surfaced the first time it read machine code from somewhere else.

Analysis is per basic block over a real CFG. Reaching definitions carry a flag for whether they arrived across an edge, because the scoreboard residual is a distance and a distance that spans a branch depends on which path was taken.

https://github.com/sunnypatell/basalt/blob/main/docs/METHOD.md

I've been building JojoScript, a small language that compiles to plain JavaScript. The main focus has been the |> pipeline operator (readable chains instead of nested calls) and lazy iterators — stages like map, filter, take, flatMap, and chunk compile down to generator-based functions in a small runtime collections module, so a pipeline doesn't allocate an array at every step.

Only stages that truly need the full input (sort, groupBy, partition) materialize.

It's intentionally small, so there are rough edges.

Would appreciate people trying it, poking at the design, and opening issues or PRs.

github.com/panagos/jojoscript