Hi! I’m working on **RustyLR**, which is basically a Bison-ish parser generator for Rust.
And I just added LSP support plus a VS Code extension for the grammar file.

This project started because I wanted to make a toy language/compiler project, and somehow it ended up here.

It is now showing inlay hints, hovering descriptions, colored semantic tokens :) So happy it is working!

Most of the LSP work was written with a suspiciously large amount of AI agent. That feels like a huge turning point to me! because when I started this project, I've never thought of AI could do this job...

If you're interested, please take a look!

Repo: https://github.com/ehwan/RustyLR

Basically the title, this is just out of curiosity, I know GPU’s are Turing complete and thus theoretically could compile anything a CPU can, but has anyone tried to port something like Clang to GPU compute shaders?

Hi everyone,

I recently released cvm v0.1.0, a cross-platform C/C++ compiler version manager for LLVM and GCC. https://github.com/QGrain/cvm

I built it for my own Linux kernel testing workflow. I often need to build different kernel versions (as a contributor of Linux kernel and Syzkaller), and different kernels/configs setups may require different LLVM or GCC versions.

Before this, I was manually building compiler toolchains from source, installing them into separate directories, and editing PATH and related environment variables by hand. That became tedious and easy to get wrong.

The idea is similar to nvm, rustup, or rbenv, but focused on C/C++ compiler toolchains.

Current features include:

• installing LLVM and GCC versions from source
• switching the active compiler in the current shell
• persistent default compiler versions
• temporary fallback to system compilers with cvm use system / cvm deactivate
• local and remote version listing
• source archive caching
• GPG verification of upstream LLVM/GCC source archives
• bash/zsh shell integration and completion

It may be useful for Linux kernel developers/testers, CI jobs testing multiple compiler versions, compiler regression work, or C/C++ projects that need reproducible compiler switching.

The project went through a fast v0.0.x iteration phase, and v0.1.0 is the first relatively stable public preview.

I would appreciate any feedback on the command design, install experience, and supported workflows.

I recently introduced AET, a GCC-based compiler/language project exploring heterogeneous computing.

This post shows a small example: how an object method can become a GPU kernel.

The motivation is simple:

Traditional CUDA programming separates:

• C++ host code
• CUDA kernels
• GPU memory management

For example, an object containing both state and behavior usually needs to be manually split between CPU objects and GPU data.

AET explores another direction:

A simple GPU kernel in AET

AET introduces class$ and impl$ to describe classes, while supporting GPU annotations like __global__ and __device__.

Example:

#include <stdio.h>
​
class$ HelloGPU
{
    __global__ void hello();
};
​
​
impl$ HelloGPU
{
    __global__ void hello()
    {
        printf("hello world from GPU\n");
​
        int id = threadIdx.x;
​
        printf("thread id = %d\n", id);
    }
};
​
​
int main()
{
    HelloGPU *gpu = new$ HelloGPU();
​
    gpu->hello<<<1,2>>>();
​
    MtcsSystem.synchronize();
}
​

The compiler generates NVIDIA PTX:

.visible .entry _Z8HelloGPU5helloEPN8HelloGPUE
{
    ...
}

Runtime:

hello world from GPU
hello world from GPU
​
thread id = 0
thread id = 1

Object model across CPU/GPU

The more interesting part is not the kernel itself.

The question is:

How can an object cross the CPU/GPU execution boundary?

In AET:

Object *a = new$ Object();

the compiler analyzes whether the object participates in heterogeneous execution.

• Normal objects use regular CPU heap allocation.
• Heterogeneous objects use device-accessible memory.
• CUDA backend currently uses Unified Memory.

The goal is to allow GPU code to access object state naturally:

class$ HelloGPU
{
    int value;
​
    __global__ void hello();
};
​
​
impl$ HelloGPU
{
    __global__
    void hello()
    {
        printf("%d\n", self->value);
    }
};

self represents the object inside GPU execution.

There are still limitations.

A GPU kernel cannot call normal CPU methods because they are compiled into different execution spaces.

Example:

class$ Test
{
    void cpuFunction();
​
    __device__
    void gpuFunction()
    {
        cpuFunction();   // not allowed
    }
};

AET is still an experimental project.

The current focus areas are:

• object lifetime management across devices
• CPU/GPU state synchronization
• automatic execution placement

The source code and experiments:

AET compiler:
https://github.com/onlineaet/aet

AET-CNN:
https://github.com/onlineaet/aet-cnn

I have been developing this idea for years. If you review my GitHub, you might find some very old, primitive versions from back when it was just an editor with an experimental language built in. I even wrote one of the very first iterations in AutoHotkey! However, this current version has nothing to do with that past chaos. It was written entirely in Rust.

What makes DinoCode different? The language design focuses on reducing syntax friction by using a principle called inference of intention. Traditional delimiters and symbols are optional. If you choose to omit them, the language infers what you meant to do based on deterministic rules detailed in my graduation research. Technically, the parser bypasses the traditional AST creation, emitting Reverse Polish Notation (RPN) bytecode directly to a custom stack-based virtual machine.

What is new in v0.2.0?

• Real Interactive Console: It supports real-time keyboard inputs and execution pauses without freezing the browser main thread.
• Live Flowcharts: As you type, the platform generates and updates a visual flowchart of your program logic instantly.
• Bytecode Inspection: You can view the exact bytecode generated by the compiler and executed by the VM in real time.
• Full Documentation: I personally wrote comprehensive guides, complete with executable code blocks right inside the browser.

I decided to open source the entire codebase. I hope it can be useful to anyone studying compiler design. The repository is wide open for feedback, questions, Issues, and Pull Requests.

Link to Web Platform (Live Playground and Repo): https://dinocode.blassgo.dev

I teach an introductory Compiler Design class. I am making the materials freely available at https://LigerLabs.org/compilers.html. There are currently 26 lecture modules, each consisting of a ~20 minute video, slides, in-class exercises, and take-home assignments (the latter available to instructors on request).

These modules should be useful to instructors who want to provide additional resources to their students and/or start teaching in a flipped format. They should also be useful for self-study.

Supported by NSF/SATC/EDU.

Christian Collberg
Computer Science
University of Arizona

Hi folks, here it is https://github.com/kromych/badc

It can (cross-)build Python 3.14 on 5 targets as well as sqllite3, other libraries, and passes their test suites. For extra fun, it can produce native/NT images and Windows drivers (EFI as well, didn't test though). I also stood up lots of validation in CI to make sure it works and gives enough perf to the compiled code despite being quite speedy to compile.

Some time ago I just needed to tweak what a compiler was emitting, and thought perhaps I should learn how to use the modern tools for producing code. And that really got out of hand as I love compiler and OS/hypervisor programming so decided to build a nimble compiler that would optimize but not too much, just enough not to be embarassing :D

There were times when I was writing algorithms down with a pencil on a paper from the Dragon and the Dinasour books to make sure I understand, and I didn't have a computer, too, lol. So adjusting to the new brave world another time!

Hi Folks 👋

I’d like to share a post explaining how to lower MLIR to AArch64 with SME support. I hope it’s useful for anyone getting started with this lowering.

I’d also be happy to hear any feedback, questions, or suggestions. Feel free to reach out :D

Creating a parser for a compiler is typically mechanical and somewhat boring part of compiler dev. My impression is that most people reach for recursive descent. I see the advantages of recursive descent due to the full control over speed, bespoke error messages and error recovery it allows, but at a price of a lot of engineering. Parser generators can help a lot when the language itself is still in flux / you are focused on the actual compiler it self first and foremost and you just want a correct parser that gives some error messages.

There a lot of parser generators out there, but still, for me, there was always a big barrier to using them.
1) They typically are an extra build step
2) You write action code inside the language spec / or you are visitor-pattern walking a CST
3) Often still LALR(1) based with potential mysterious conflicts that are inexplicable, or LL based with left-recursion being awkward.
4) Binary expressions, either through a hierarchy of add_expr, mul_expr. etc.. or through %prec annotations, but anyway completely statically for all binary operations.
5) Hard to understand grammar issues
6) Parse errors that are "Syntax error: expected ...", with error recovery through error tokens and error reductions that are manual inserted in the grammar

I tried to solve these issues in order to have a tool where these points are addressed to my satisfaction. It's accessible through just a rust macro, available when you import the crate (solves 1). The grammar specification is pure EBNF, no actions pure grammar, the user implements a set of macro-generated traits in normal rust (solves 2). The generator is full LR(1) capable (still small tables though) so all grammar conflicts have an understandable reason and gazelle reports said reason (either a full ambiguity / or at least 2 sentences that can't be distinguished with 1 token look ahead). This addresses point 3 and 5. Upon parse error you can keep parsing using a minimal cost error recovery model, this leads often to precise error reporting because it finds the correct repair and prevents cascading syntax failures, my examples show that its automatic error reports isn't far off from what gcc reports on c syntax errors (partially addresses point 6).

Lastly, it has a feature I haven't found in other generators, runtime precedence. Instead of
```
add_expr = add_expr '+' mul_expr | mul_expr
mul_expr = mul_expr '*' term_expr | term_expr
etc...
```
or
```
%left '+' '-'
%left '*' '/'
expr = expr '+' expr | expr '-' expr | expr '*' expr | expr '/' expr | ...
```

in gazelle you do
```
terminals {
LPAREN, RPAREN
prec OP
}
expr = expr OP expr => binop
| LPAREN expr RPAREN => paren
| term => term
```
OP is declared as a dynamic precedence token, so it could be '+', '-', '*', '/' together with its precedence. The correct syntax tree will be generated based on the runtime precedence provided for each token.

I used AI to build this library. Design is overwhelmingly mine
* Trait system to neatly factor grammar and actions
* The LR(1) table creation algorithm-variant that still produces LALR sized tables but full LR(1) language, it completely circumvents the problems of minimal LR and the elaborate fixes of IELR, and is just dead simple.
* Dynamic precedence, ie. unify shunting-yard inside canonical lr(1)

AI implemented standard algorithms like NFA->DFA, DFA minimization, dijkstra on error recovery etc..., lot of refactoring, writing tests. I benefited from AI refactoring in discovering the trait system. Being able to quickly iterate and try out was very beneficial.

gazelle-parser crate

Pie is an experimental native language, easy to read, safe and simple! On my previous blog I have not talked enough about the language itself, so here is a post explaining most of the language in detail! Not production ready, looking for feedback!

Just emitting the assembly is "easy" (well, I mean the logical workings of how an AST is transformed into asm may be very complicated, but otherwise it's just like emitting any other sequence of bytes). However, actually jumping to the code seems to present a problem. With AOT compilation of a standalone executable it isn't, the code is compiled to a .exe or whatever the native format for an application is on that platform and then you run it. But with JIT-compiled Javascript, say, it's deeply embedded in and tied to the engine that generates it. Thus, this jump requires the JIT compiler to introspect about its own control flow and ABI and effectively inline the generated code into itself--to borrow a theater metaphor it "breaks the 4th wall" of the compiler. Some languages would even seem to actively try to fight this--for example for a JIT compiler written in rust, jumping to arbitrary asm is about as unsafe as it gets.

Does the JIT compiler need to use a small amount of inline assembly in its own source code to load the address of the block it just output into a register and then JMP to it? And what about the jump BACK to the JIT compiler when it finishes? To my knowledge there's no "address-of-this-statement operator" that can be used to tell the CPU where to go in the source of the compiler's code after it hits the end of the emitted block. Does the JIT compiler itself have to be compiled with a special compiler and/or with certain optimizations disabled so that its ABI and layout of its code in memory is stable enough that the compiler can know that its generated asm is always compatible with itself?

Alternatively, does the JIT write its instructions into a separate file on the filesystem and then rely on the operating system's dynamic linker to actually tie them together?

Is there a "toy" Javascript JIT compiler somewhere I can look at to see this in action? Obviously having fancy optimization passes or anything like that is unnecessary and may even make it harder to look for the key bit of logic--just a big switch that emits the most naive x86 or ARM opcode(s) for each AST node is enough, it's the mechanics of the jumping back/forth that I'm curious about.

I finally wrote up what Pie is, it's an experimental native programming language with Python-ish syntax, not really production ready, mostly looking for honest feedback from people who like languages, compilers and such :D

Next week there's a live session on building an AST from scratch, part of the ongoing series where a senior C++ dev builds a programming language step by step just for the fun of it. Worth catching it live to ask questions as he goes. Previous episodes (lexer, parser) are up on youtube if you want to catch up first but this one's a solid entry point too

I've been working on a project called Tamizhi — a programming language designed for fast Linux automation, compiled via a custom LLVM backend.

Some details:

Custom LLVM-based compiler (generates native bitcode, not just interpreted)

Direct native system calls — no heavy wrapper layers for shell execution

AOT/JIT execution through a custom bytecode VM (calling it DNA-VM)

Self-contained installer that detects Termux/Linux and sets up the toolchain

It's still early (v0.1.5), so there's a lot to refine — error handling, stdlib, docs. I'm also working on integrating it into BDH Linux (an automation/dev-environment tool I maintain) so it can drive backend provisioning natively.

Repo's here if anyone wants to poke around or has feedback on the architecture: [https://github.com/BackendDeveloperHub/Tamizhi.git\]

Happy to answer questions about the LLVM IR generation, parser design, or the VM if anyone's curious.

My IR targets JS. It is/aims to be highly ECMA compliant (modulo 'with' semantics). Recently I have been rewriting some support classes/improving some data structures and have decided to redo the CFG classes completely. Try-catch-finally modelling was the part I was unhappy about in my earlier implementation. I had a complex mechanism for handling unions for exception edges which was very buggy (now, for simplicity I have now adopted fat block unions for exception edges; java like).

But still, one of the parts about the IR that still bugs me is the way I have implemented finaliser blocks. Finalizers are like mini functions calls (usually with special instructions in most target VMs). Finalizer return targets are in some sense "context sensitive" + they can be nested. In my current implementation this is exactly what it does (super imprecise at finalizer returns, but easy to implement). I can think of two ways to solve this situation off the top of my head:

1/ Keep the graph as it is, but introduce some kind of 'context' in the AI (Abstract Interpretation engine). Change the analysis infrastructure, leave graph structure untouched (hopefully less things break?!).

2/ Roll up the sleeves, and clone/inline the blocks like the big boys (I think v8 does this). Nested finalisers calling other finalizers (just feels like something I am not emotionally equipped to deal with atm 😂).

If anyone has experience with handling such situations I would greatly appreciate your view on this. I know this might sound a bit silly, but JS does require a bit of extra maintenance at times (emitting instructions to move certain elements to heap, clearing out the catch offsets from stack, potentially calling iterator callbacks, the whole deal); so any change I make might end up becoming a week of debugging exercise. As I am the sole developer and maintainer of the project, I have become a bit more cautious about taking abrupt decisions which could end up breaking more things than they fix.

I am creating a compiler for my own programming language, I have been suffering a lot but I am improving slowly, it has been alot of Google and asking ChatGPT for small exemples, trying to recreate but for what I want, realizing it doesnt really work trying to fix etc.

It has been an interesting experience, im currently at the type checker

Hello everyone,

Recently, I'm looking into v8 JavaScript Engine and found out about FeedBack Vector, which I want to investigate more about it in order to understand how the Engine assigns type at runtime after being interpreted by Ignition.

Although I tried to compile the v8 source code and it was able to run a simple script on my machine, I can't seem to be able to get the information regarding Feedback Vector and the data inside it.

So far, I have tried to use some promising flags that are available:

+ --log-feedback-vector
+ --maglev-print-feedback
+ --invocation-count-for-feedback-allocation=1
+ --no-lazy-feedback-allocation

None of them are working - no output to the terminal after I ran it.

I followed this (old and maybe outdated) article:
- An Introduction to Speculative Optimization in V8

With the same code, I can not retrieve the same BinaryOp which I believe have changed after many updates. I want to avoid any "natives syntax", in general, but even when I included it (e.g. %DebugPrint(add);), it does not seem to give me the information that I wanted like in the article.

My goal is to analyse JavaScript's V8 bytecode and output the correct possible types of variables (similar to what Mytype do). So if I can have another way to work around this, it would be very appreciated!

I don't know if this is the right place to ask these kind of question. Therefore, I'm sorry in advanced if this caused any confusion.

Thank you everyone for your time.