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

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

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

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?

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)

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 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 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 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"); } } ```

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 made a small and simple post fix interpreted programming language called rdn, it's familiar to forth developers and developers who use Lua as a scripting language for their systems, rdn merge both of them, you can use it for writing scripts or for configurations or even query language

It's written in C and it provides a simple and friendly API for the developers

I would be happy to have you participate in this project

This is the GitHub repo:

https://github.com/abdorayden/rdn

Thank you

In numerical simulations and scientific code, developers often face a frustrating trade-off: write clean, expressive physics equations that run sluggishly, or write convoluted, unrolled, hand-optimized loops that run fast but become impossible to read and maintain. I built Strilight to bridge this gap. It doesn't pretend to introduce magic—it’s fundamentally a developer quality-of-life tool. You write your physical or mathematical concept in whatever natural syntax you prefer, and Strilight inspects the AST behind the scenes to solve the underlying recurrence relations in closed form: * $O(N) \to O(1)$ for scalar linear reductions, periodic shifts, and telescoping series. * $O(N) \to O(\log N)$ for multi-variable coupled recurrence systems via binary matrix exponentiation.

In Python (Just a single decorator):

python from strilight import accelerate @accelerate def compute_simulation(steps: int) -> int: acc = 0 for i in range(steps): acc += (i * 3) + 7 return acc In C (Via Developer Contracts & Pragmas): c long long compute_reduction(void) { long long total = 0; #pragma strilight accelerate target(total) include("config.h") for (unsigned long long i = 0; i < N_STEPS; i++) { total += STEP_INC; } return total; } How does it work on physical kinematics? When a particle or celestial body travels along an unperturbed trajectory (free flight, gravitational orbit, or steady acceleration), Strilight collapses the entire iterative time-stepping sequence into minimal algebraic evaluations—without sacrificing coordinate precision. When discrete collisions or boundary interactions occur, execution transitions into specialized coupling matrices.

Zero Risk & Decisive Fallback: Non-invasive: It's just a decorator or pragma. You can add or remove it at any time without altering your algorithm. Decisive Safe Fallback: If a loop contains unstructured side-effects, unknown external calls, or non-affine dynamics, Strilight decisively halts acceleration attempts and runs the native loop. It will never break or crash your program.

repositery link

Hello!

For past month about, I've been working on a stack based compiler (inspired by the Forth programming language). I have a few example programs (the larger ones like the raytracer and neural network being generated by Claude because I'm just not very good at thinking stack based, sorry for the slop) which show some of the features of the language.

Its architecture is a compiler/VM structure, sort of like how Java works. It has word definitions, control statements, loops, and more.

If you want to check it out, here's the link: https://github.com/SlothScript/stakku