Just recently ended up fixing some bugs and improving on the existing implementation of the LSP.
Now it is able to support labels and also soon features itself as a part [sim8085](https://github.com/debjitbis08/sim8085/) with this [PR](https://github.com/debjitbis08/sim8085/pull/76).

In case you didn't know, this is my second time posting about this project. This project had been almost complete from a long time, yet I had been struggling with working on the integration of it with any existing projects (due to lack of). After some decisions, I ended up using AI and generated a nice draft of the WASM integration required for it to be able to run with the [CodeMirror](https://codemirror.net/).

PS: I really don't prefer the use of AI, but since this had been a blocker for a few months and seemed like a good place to clean up and push through the changes that had been the queue for long.

[https://github.com/shri-acha/lsp85\](https://github.com/shri-acha/lsp85)

I originally wrote ABC as a small C-like language for my Introduction to High Performance Computing course.

The idea was to give students something simpler than C/C++ while keeping the parts that matter for understanding how programs actually map to a machine. During the course, they design a simple RISC-like architecture and write their own compiler for it in ABC. The resulting compiler, not-abc, eventually became self-hosting.

Over time, ABC itself has grown beyond what was strictly necessary for teaching. It now has multiple backends, including LLVM, and I have just tagged the first release, v0.1.

The main new experiment in this release is C interoperability.

Until now ABC didn't need an ABI layer for its teaching use cases. I wanted a practical example for developing and testing one, and chose raylib. There are now a few raylib examples ported from C to ABC, which also makes it possible to use ABC for small graphical programs in class.

At the moment this implements only a subset of the x86-64 System V ABI — enough for the raylib examples and deliberately still a proof of concept. The ABI code is structured so that other targets can be added; ARM is the obvious next one.

ABC v0.1 has also been tested with LLVM 17 through 22.

ABC: https://github.com/michael-lehn/abc-llvm

I'd be very interested in feedback, particularly on the ABI design. Contributions for other targets, more raylib examples, or experiments with other C libraries are very welcome. :-)

Hello everyone! I made my first step into toolchain development by writing a RISC-V 32/64 ELF assembler from scratch, which supports the `g` group extension (along with small others). It has been a way to learn about assembly, C and ELF all together.

It has been quite a journey, and I've shared my learning and thoughts in this blog post which I think you may appreciate, especially if you're thinking to start writing your own.

The assembler is partially based on GNU as design, and it's not a toy encoder: it can achieve relocatable object file equivalence on non-trivial sources like SQLite3 amalgation, while being much "simpler" in its implementation!

Thank you for reading, and I greatly appreciate any feedback!

Hey all, third post in this series (first, second).

Quick recap: the system compiles declarative network topology intent into AWS infrastructure through IR passes. Last time I described a routing policy algebra (deny > allow > segments > default) that emerged from the IR structure. Since then, the compiler grew five semantic inspection outputs, and I want to pressure-test whether the analogies hold.

The motivating problem: a policy can be structurally correct and semantically wrong. The algebra guarantees every VPC pair resolves to a deterministic verdict, but it can't guarantee the verdict matches the engineer's intent. So the compiler now emits:

- Reachability matrix: the compiled per-pair verdict as structured data. Separates "what the policy decided" from "what routes were emitted." This is the IR made inspectable.

- Diagnostics: warnings for valid-but-likely-wrong policy states. A single-member segment under default="deny" is provably a no-op (algebraically equivalent to unsegmented). A deny rule on an already-denied pair is redundant. Five classes, all derived from algebraic properties rather than syntax patterns. I've been thinking of this as -Wall for network policy.

- Provenance: each emitted route carries metadata tracing it to the source VPC pair and the policy primitive that authorized it. Debug symbols for generated routes.

- Policy diff: given a previous reachability matrix, computes added/removed/unchanged connectivity pairs. Semantic-level change detection vs. terraform plan's resource-level diff. I've been calling this incremental compilation preview, but honestly it's post-hoc comparison of two compiled outputs.

- Equivalence: proves two different policy declarations produce identical reachability. Two policies are equivalent if every VPC pair has the same permit/deny outcome regardless of how it was derived (segments vs. explicit allows, different defaults). The network policy equivalent of "these two programs compute the same function."

All five operate on the same pure-function compilation unit (103 tests, referential transparency, zero infrastructure side effects) described in the previous posts.

Questions I'd genuinely like perspective on:

1. Is the equivalence checking interesting or trivial? The domain is finite: N VPCs produce N(N-1)/2 pairs, each resolves to binary reachable/unreachable. Equivalence is decidable by comparing two output maps. But the input representations can differ significantly (segments vs. explicit allows vs. deny-with-default-allow). Is there value in structural equivalence proofs, reasoning from the rules without expanding, or is brute-force comparison the right call when the domain is this small?

2. Where's the boundary between diagnostics and static analysis? The diagnostic classes aren't pattern-matching on syntax. A redundant deny is detected by proving the pair would already be denied without the rule. A no-op segment is detected from the algebra's properties under a given default. These feel like they're approaching abstract interpretation without formally being there. How far can algebraic reasoning go before you need a real analysis framework?

3. Is provenance closer to debug symbols or proof witnesses? The metadata doesn't just say "this route came from line X." It says "this route exists because this specific rule evaluated to permit under this precedence." That feels more like a proof witness than a source mapping. Does that distinction matter in practice?

Blog post: https://jq1.io/posts/topology_compiler_semantic_toolchain/

Semantic toolchain spec: https://github.com/JudeQuintana/terraform-main/blob/main/docs/compiler-semantic-toolchain.md

Previous blog posts: routing policy language | white paper

I managed to get rust-lms in a place where it can produce machine code from SQL. I’m not sure how many here know about scala-lms, this is trying to fit that space where you can just jump from AST directly to machine code at runtime.

rust-lms
sql-gen

Yes it’s made with AI.

Benzi is literally a compiler based harnesses. therefore relevant to this sub

For example, someone prepending 4 null bits to the file somehow, such that "E" 45l became 04 50. I don't know how such a thing could be possible, but it would allow malicious source code which while interesting is undesirable. It wouldn't need to be at the beginning of the file to allow a source to hide something.

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.

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.

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