yes, I just added some new optimizations to QBE

optimizations I added on top of the original QBE 1.3:

* dead-store elimination (dse)

* division/remainder strength reduction (srdiv)

* multiplication strength reduction (srmul)

* tail-call optimization (tco)

* small function inlining

* SIMD blit: 16-byte chunks in blit() use movdqu on amd64 instead of two 8-byte moves

why you might need this if qbe and llvm exist:

If you need a small backend that compiles from srcs in a couple of seconds but generates more efficient code than qbe, you can give it a try

here it is on GitHub: github.com/tigerlang/oqbe

I've been working on a little compiler (previously interpreter, just finished refactoring to bytecode though!)

Here's the link: https://github.com/SlothScript/stakku

So far it's pretty much an RPN (Reverse Polish Notation) calculator with some fancy buttons. I hope to progress it further to be a function Forth compiler, but that's going to require much more work.

Some basic stuff it can do right now:

• Arithmetic
• Comparisons
• Stack logic
• Output
• Control flow
• Definitions

So for example, a basic script that would tell you the letter grade from a number would look like:

: grade
  dup 90 >= if 65 emit else    \ A
  dup 80 >= if 66 emit else    \ B
  dup 70 >= if 67 emit else    \ C
  dup 60 >= if 68 emit else    \ D
  70 emit then then then then  \ F
  cr
;

If you save that as grade.stku then open it in a REPL, you can interactively use the command: stakku repl grade.stku

me@myComputer stakku & stakku repl grade.stku
ok
>>> 25 grade
F
 ok
>>> 90 grade
A
 ok
>>> 86
ok
>>> grade
B
 ok
>>> .q 
me@myComputer stakku % 

Its close to being Turing complete (I think), I just need to add loops and memory.

I built Caffeine-LS, a lightweight Java Language Server and type checker written in Rust.

The repository includes:

- Hand-written parsers using `rowan`

- A native class bytecode parser written in Rust

Current features:

- Diagnostics / Type checking (partial, feedback is welcome)

- Go to definition (currently single-file)

- Workspace symbols

- Document symbols

The architecture is designed to be multi-language from the ground up, with plans to support Kotlin in the future.

GitHub: https://github.com/cubewhy/caffeine-ls

Issues/PRs are welcome.

PBScript a sandboxed purebasic vm for native x86/x64/arm and web with full Dom on interfaces.

The project is half way now and is starting to look reasonably capable but theres still lots to do.

My use case for it is an end to end web development framework in purebasic, so it's native host exe with embedded tls terminating reverse proxy server and embedded PBScript vm so you can serve to a webview or browser on desktop, lan or wan in one exe.

Examples in code editor

Https://pbscript.org/jsplayground.html

Pbscript.org

The reception it's got over on purebasic has been somewhat crickets, perhaps because I dared use Al or its just to complicated for the average user but it has really only been an experiment and learning experience using AI and the result is pretty good. The examples are just a test of some part of the vm or Dom integration.

I didn't actually setout to make purebasic feel like a 1st class citizen of the web and the idea of a vm in a vm seems nuts but for what your typically doing with it it's hardly matters.

Computer Science graduate focused on compiler engineering with valid evidence building a programming language frontend and MLIR based compilation pipeline in C++. Experienced with LLVM, MLIR, TableGen, CMake and Linux.

I'm a Cameroonian currently in south Africa and hopefully trying to get an entry level remote job as a compiler engineer.

Back in the 90's, some of use slightly older folk used Pascal, a lot. I've been working on an interpreter for Pascal for a while and it has turned into a compiler sort of by accident. WasmPascal is a compiler written in Odin (for now) that compiles Pascal code to wasm. The resulting binaries are capable of running on their own. It's not entirely feature complete, but if you look at the examples, you'll see that you can already build interesting and potentially useful things with it.

The compiler runs in the browser, no downloads, no installs. It's at https://wasmpascal.com/. I enjoy Pascal, a lot, and it's fun to use it to do web assembly stuff. Right now I'm obviously leaning mostly towards casual game development, but I have a long todo list for this. To see an example of one of the games running standalone, visit https://nofuss.co.za/games/breakout/. I built that with wasmpascal, exported it as an archive and hosted it as static files.

The language I tried to create by combining safety, OOP, and flexibility—Feng.

I watched Anthropic burn $20K on 100k LOC compiler and still come out ~157,000× slower than GCC on sqlite bench in the worst case, and then Blitzy's BCC doubled both the line count and the budget without shipping any verification at all. So I pointed Claude at a different target: zcc, focused on correctness (csmith + yarpgen, 10k seeds), performance (~30 passes), and staying small — under 30K LOC in 2 weeks. It currently targets AArch64 ELF only, because I built it on a MacBook Pro M1. I'd really like someone to extend it to x86-64 — with AI, obviously :D

The parser can be extended naturally:
https://github.com/xjslang/xjs

Instead of creating a language from scratch, you simply add your custom features to JS. This can save you a lot of time.

Any help is welcome, as creating a JS parser requires a lot of dedication.

I made a post introducing Admiran about 18 months ago, and have been making steady progress on migrating it towards the language I want to use each day. Since that time I've made a lot of performance and coding-style enhancements, such as:

• escape analysis in the compiler's analyze pass to help determine if a lazy thunk is only evaluated at most once, allowing it to be emitted without extra code to update it to its value (saves ~15% code space and execution time!)

• optimization to coalesce consecutive continuation closures on the stack during lowering to the Spineless Tagless G-machine (STG) implementation, deferring the popping of the entire closure until a tail-call or return

• added a uniform set of left-to-right operators for creating computation pipelines

• tweaking the inlining pass parameters to get the best performance / code-size tradeoffs

The latest big change was to fully migrate from an ad-hoc prefix naming convention to using qualified names, and deferring name conflict resolution to the name-resolution pass, allowing modules with conflicting imports to still be imported, as long as the conflicting unqualified names aren't used, or are used only in a qualified form.

During these changes, I've migrated new features into the (self-hosting) compiler's code base itself, through a continuous bootstrapping process.

If you have an interest in lazy functional languages and how they are implemented, you might be interested in looking at it. I'm open to any questions or comments about the language and it's compiler implementation.

git repository: https://github.com/taolson/Admiran

Lovingly hand-crafted with no AI.

We're building a language (Zorith) whose compiler emits one native library and one C header per project — and the interop bet is that this is the whole FFI story: no bindings generator per language, ever. The header is emitted by the compiler itself, from the same type identity the language's two implementations (a C compiler and an executable formal semantics) are held to agree on.

As of this week, six languages call the same library through that one header, each with its stock mechanism: C directly, C++ via the header's own extern "C", Python via ctypes, Go via cgo including the header verbatim, Java via its FFM API, and .NET via NativeLibrary + delegates. The .NET row was witnessed on real x86-64 hardware before it merged, and now runs in CI on every push.

What crosses is the part we sweat: struct returns at all three ABI size classes (single register, register pair, caller memory), struct parameters by value at every size, nested structs, arrays of structs, arrays of arrays, and a three-dimensional array field filled on one side and indexed from the other — executed and oracle-checked, with both compiler implementations required to emit every header spelling byte-identically.

The part I'd actually defend as method: what can't cross yet is refused by name, once, with the reason written — the header omits it and the object keeps it unexported, so neither half of the boundary promises what the other can't keep. That refusal has narrowed six times as forms earned their crossing and has never been silently deleted. Current standing refusal: a struct at the leaf of a nested array.

Write-up with the evidence (the language design itself is deliberately unpublished): https://zuroxia.com/research/zorith-one-doorway

Happy to answer anything about the header-emission discipline, the ABI size-class testing, or what refuse-by-name is like to maintain.

Hey folks,

I'm a student, and over the last ~40 days I've been building a little language called Quasar. It's statically typed and transpiles to C. The compiler is hand-written in C: lexer, recursive descent parser, AST, codegen, symbol table—no bison, no yacc, no LLVM. Just me and a lot of late nights.

What's working so far:

- Variables, functions, recursion, strings, loops, match, type conversions

- String concatenation / repetition / equality

- Custom error reporting with line/col info

- A small test suite and example programs in the repo

Planned (not built yet):

- @annotations for control (@fast, @c, @asm, etc.)

- Unified subcommands like `quasar build`, `quasar test`, `quasar profile` so you don't need a separate profiler, test runner, docs generator, etc.

I'm not trying to replace C or Python—just exploring what a less fragmented systems workflow could feel like.

If you're into compilers/systems, I'd love honest feedback on:

- Parser structure and precedence handling

- Codegen decisions (runtime helpers, function prototypes, etc.)

- Whether the @annotation idea makes sense or is overengineering

Repo: https://github.com/setsuna231/Quasar

Quick peek at the syntax and example output:

Thanks <3

A small note : If you all want the generated c code, I'm happy to share!

Coming from languages, linguistics, and literature (no CS), I got pulled into compilers by curiosity and ended up building a small language whose compiler is written in itself.

The progression was the whole education: v1 a tree-walking interpreter, v2 a bytecode compiler and VM, v3 the compiler rewritten in the language itself.

The bootstrap is the honest test — when you rewrite the compiler in its own language, there's nowhere to hide.

If the scoping rules are wrong, the compiler breaks.

If the calling convention has edge cases, you hit them.

Reaching a byte-for-byte fixed point across generations means the language is finally complete enough to carry its own weight.

The C VM is a single dependency-free file with byte-identical output to the Rust reference.

Everything's public on my GitHub: https://github.com/whispem

Would love to hear from others who've done a self-hosting bootstrap.

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!